Reviewed:  https://review.openstack.org/310648
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=3e66b1a87544d7a127abceec13bfeacb8f18f7e1
Submitter: Jenkins
Branch:    stable/mitaka

commit 3e66b1a87544d7a127abceec13bfeacb8f18f7e1
Author: Dustin Lundquist <email address hidden>
Date:   Thu Mar 31 15:19:04 2016 -0700

    IPtables firewall prevent ICMPv6 spoofing
    
    IPv6 includes the concept of link-local addresses. There are address
    within the fe80::/64 prefix which are used only within the local layer 2
    network. They should never be routed. DHCPv6 is one of several protocols
    which utilize link-local addresses.
    
    Previously the blanket permit DHCPv6 rule permitted DHCPv6 requests from
    a link-local source, before the source address was validated.
    
    The structure of the IPtables egress firewall is:
    
      a. fixed rules for special traffic
      b. validate source address
      c. fixed rules necessary for host to function
      d. user rules defined by security groups
    
    This change restricts the special traffic permitted in part (a) to only
    that traffic which utilizes the "unspecified address" (::), by moving
    the fixed permit ICMPv6 and DHCPv6 rules to part (c), so they are
    applied after the source address has been validated. In order to enable
    DHCPv6 and other protocols utilizing link-local addresses, the
    link-local address corresponding to each MAC address are included in the
    permitted source addresses. After the source address is verified, the
    fixed rules permit ICMPv6 and DHCPv6, then the user defined security
    group rules are applied.
    
    In the existing implementation ICMPv6 and DHCPv6 rules in the fixed
    ip6tables firewall rules are too permissive: they permit ICMPv6 and
    DHCPv6 traffic, regardless of source MAC or IPv6 address. These rules
    where intended to allow a host to acquire an IPv6 address, but
    inadvertently allowed a malicious or compromised host to spoof another's
    MAC or IPv6 address.
    
    A host acquiring an IPv6 address should preform DAD (duplicate address
    detection). To preform this the host must join the multicast group
    corresponding to the tentative IPv6 address and the all nodes multicast
    group. To join these groups the host sends ICMP MLD (multicast listener
    discovery) report messages before it has an IPv6 address assigned, so
    the unspecified address is used as the source address. To complete DAD,
    ICMP neighbor solicitation messages are sent to solicit if any nodes
    using that address. This should be the only use of the unspecified IPv6
    address as a source address. The IPv4 case is similar the unspecified
    address is used for DHCP discovery and request messages.
    
    To summarize, this patch permits only ICMPv6 traffic from the unspecified
    address which is used for duplicate address detection. Then it enforces
    the source IPv6 and MAC addresses and finally, allows only ICMPv6 traffic
    which has passed this source address validation.
    
    In addition this patch permits traffic from all link-local addresses
    associated with each MAC address assigned to the port. This is required
    by many IPv6 protocols, such as DHCPv6, which depend on the link-local
    addresses. This traffic was previously allowed by the blanket allow
    ICMPv6 and allow DHCPv6 rules before the source address was validated.
    
    Finally, it includes a functional test for IPv6 spoofing using both
    ICMPv6 and DHCPv6 traffic. OVSFirewall currently permits this spoofed
    DHCPv6 traffic. I'm excluding the OVSFirewall implementation from test
    so it can be fixed in a follow on patch.
    
    Conflicts:
    	neutron/agent/linux/iptables_firewall.py
    	neutron/tests/unit/agent/linux/test_iptables_firewall.py
    
    Change-Id: Ice1c9dd349864da28806c5053e38ef86f43b7771
    Partial-Bug: 1502933
    (cherry picked from commit a8a9d225d8496c044db7057552394afd6c950a8e)