Thursday, January 5, 2017

enforcing DNSSEC client validation with FAUCET

DNSSEC is considered very important, because it provides a way for a DNS client to validate results.

However, not all DNS servers, will perform this validation on behalf of their clients (or the clients may be configured to use the wrong resolvers).

Using FAUCET with some NFV, though, you can force clients to use a validating DNS server.

First, you'll need to provide an NFV'd DNS server that performs validation. There is a guide for BIND - it boils down to a couple of extra configuration settings.

Then, you'll need to configure FAUCET to intercept DNS requests, and output them to the NFV port where the DNS server is. Here is a FAUCET config snippet that does that:

In this example, we force DNS requests, UDP and TCP, to go out port 1, VLAN 2001, which is where the NFV'd DNS server is running.

acls:
    2001:
    # Force DNS
        - rule:
            dl_type: 0x800
            nw_proto: 17
            tp_dst: 53
            actions:
                output:
                    vlan_vid: 2001
                    port: 1
        - rule:
            dl_type: 0x800
            nw_proto: 6
            tp_dst: 53
            actions:
                output:
                    vlan_vid: 2001
                    port: 1
        - rule:
            actions:

                allow: 1
...

        interfaces:
            1:
                tagged_vlans: [2001,2002,2003]
                name: "port1.0.1"
                description: "windscale"
            2:
                native_vlan: 2001
                name: "port1.0.2"
                description: "vek-x"
                acl_in: 2001


Next, we configure the NFV host to intercept those DNS requests. This can be done with iptables - for example (the NFV host's IP, is 192.168.1.1).

-A PREROUTING -i br1 -p tcp --dport 53 -j DNAT --to-destination 192.168.1.1
-A PREROUTING -i br1 -p udp --dport 53 -j DNAT --to-destination 192.168.1.1

Any client on port 2 is now compelled to use that DNS server (and only that DNS server). For example, they can visit a test site which will verify that DNSSEC is being used.

You might imagine using the same technique to force proxy other protocols, such HTTP, etc.



V1.3 released



To: faucet-dev, faucet-users


Hi all;

We have just pushed another stable release, V1.3, including new pip packages (https://pypi.python.org/pypi/ryu-faucet).

This release most notably makes a change to the pipeline (ACL table now comes first), and removes support for the old V1 config file format - only version V2 is supported.

There are a number of other changes to improve test reliability and some IP routing fixes.

Thanks,

Wednesday, January 4, 2017

LINK022 - OF controlled WiFi

In this post, I'll describe LINK022 - an experimental WiFi AP, powered by PoE, and controlled by OpenFlow (and FAUCET in particular). LINK022 can be used for practical use cases like eduroam, which is a global roaming WiFi service for research and education - which I'll describe as a working example.

Because OpenFlow is used to control WiFi traffic, you can dynamically filter, mirror, etc traffic as soon as it enters the network (rather than by the time it reaches a firewall), perhaps based on user ID - an external process can update and signal FAUCET to apply the appropriate policy.

At the moment, non-OpenFlow configuration is manually specified (eg, SSID). In the future, OpenConfig will be used.



LINK022 is based on Raspberry Pi 3. While the 3 does have onboard WiFi, it's suggested you use a separate WiFi adaptor (eg, you might want one with better/multiple antennas).

LINK022 requires a host switch that can provide PoE, and also runs OpenFlow (so both can be controlled by FAUCET).

The key software components of LINK022 are:
  • hostapd (manages the WiFi radio, and implements 802.1x authentication via RADIUS)
  • OVS (switches packets from WiFi, and implements security controls, like FAUCET ACLs)
  • FAUCET (controls OVS, and the host wired switch - runs on a separate host)
In the following diagram, LINK022 is on the left; the host switch is on the right, and the controller/NFV host (where FAUCET runs) is top right. 

FAUCET is used to implement VLAN 100 between AP and host switch, for  OpenFlow, RADIUS, and management traffic.

FAUCET also implements VLAN 2002, which WiFi clients are bridged onto, and the NFV host provides DHCP, DNS, etc, via the host wired switch.





To implement the eduroam use case, you will need to do the following (including obtain RADIUS credentials; if you don't have eduroam, you could use your own RADIUS server):

  • Set up a host OpenFlow wired switch with controller/NFV host, as above, running FAUCET.
  • Set up FAUCET config for the port, where you will connect LINK022.
            9:

                tagged_vlans: [100,2002]
                name: "port1.0.9"
                description: "link022 WiFi AP"
  • Set up FAUCET config to control LINK022 (OVS controls only the user traffic):
    link022-faucet-1:

        dp_id: 0xb827eb608918
        hardware: "Open vSwitch"
        interfaces:
            1:
                tagged_vlans: [2002]
            2:
                native_vlan: 2002
  • On LINK022, set up wired interface to use VLAN 100 by default, and set up a Linux bridge with veth pair (for OVS to connect to the WiFi radio). This is accomplished by using the following for /etc/network/interfaces:
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static 
address 0.0.0.0

auto eth0.100
iface eth0.100 inet dhcp
        vlan-raw-device eth0

auto wlan0
iface wlan0 inet static
address 0.0.0.0

auto wlanbr0
iface wlanbr0 inet static
        pre-up ip link add veth1 type veth peer name veth2
        up ifconfig veth1 up
        up ifconfig veth2 up
address 0.0.0.0
        bridge_ports veth1
  • Install OVS on the Pi (I used 2.6.1). The Pi isn't very powerful, so it will take a while to compile.
  • Configure OVS to be controlled by FAUCET, and add eth0 and veth2 to br0. Your br0 should look like this:
root@link022:/home/pi# ovs-vsctl show

6a4b6902-349e-4b99-b1ed-54338ca7ceac
    Bridge "br0"
        Controller "tcp:<FAUCET IP>:6636"
            is_connected: true
        Port "veth2"
            Interface "veth2"
        Port "br0"
            Interface "br0"
                type: internal
        Port "eth0"
            Interface "eth0"
    ovs_version: "2.6.1"

  • Install hostapd, with the following config as /etc/hostapd/hostapd.conf

interface=wlan0

driver=nl80211
hw_mode=g
channel=6
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
rsn_pairwise=CCMP
bridge=wlanbr0
ssid=eduroam
auth_server_addr=<RADIUS SERVER IP>
auth_server_port=1812
auth_server_shared_secret=<SECRET>
wpa_key_mgmt=WPA-EAP
ieee8021x=1


That's it! From now on, if you have eduroam credentials, you will be able to authenticate and browse the network.

Some further reading: