IAM
======
Name:           Anti-spoofing Link Protection
Submitter:      Eric Cheng
Owner:          Kais Belgaied
Status:         submitted
Exposure:       open


SUMMARY
=======
In many virtualized setups today, it is common for the host administrator
to grant exclusive access of a physical link or a vnic to a guest VM. This
enables guests to benefit from traffic isolation and improved performance.
The downside is that guests are allowed to generate any type of packet,
even harmful ones, to the network.

Link protection is a new mechanism for preventing potentially malicious or
misbehaving guest VMs from sending harmful packets to the network. This
feature provides protection against these basic threats: IP, DHCP and mac
spoofing; and L2 frame spoofing. IP/DHCP/mac spoofing are commonly used by
attackers for hijacking/eavesdropping communications between neighbours
within the same LAN. Spoof protection of IP and mac addresses could thwart
many variants of such attacks. L2 frame spoofing is often used by attackers
for disrupting link layer operation or bypassing security. For example: fake
bridge PDUs could cause misconfiguration of switches; packets with spoofed
nested VLAN tags could be passed erroneously on to other supposedly isolated
VLANs. One possible defence is to forbid the sending of non IP-related
packets. This is usually acceptable for most VMs since most have no need for
generating non-IP traffic.

Unlike a traditional firewall, link protection does not support inbound
filtering or customizable filtering rules. For users with such requirements,
a firewall should be used instead. Link protection has the advantages of
ease of use and performance over a firewall. At most two commands are needed
to enable it: one for selecting a protection type, another for customizing
it. Performance is better than that of a firewall because this feature is
built-in and is more tightly integrated with the network stack.


ISSUES
======
PSARC/2009/436  Anti-spoofing Link Protection
Inception 08/19/2009

gw-1    What's the administrative interface?  dladm?
        What's the policy for setting these properties?
        Near the end, what does PERM rw mean?

gw-2    Is the cred of the caller available at the place where
        packets are dropped (and the statistics kept)?
        Would it make sense to generate audit records for drops?
        (There's likely to be future Audit work to alarm for
        certain configured threats that these records could
        feed into.)

seb-01  The wording in the spec implies that all link-local addresses
        are implicitly included in allowed-ips.  That doesn't seem
        right to me.  That would imply that a zone can forge any
        source link-local address they wish...  Do you instead mean
        _the_ link local address that is formed using an EUI-64
        interface ID based on the link's MAC address?  This must be
        what you meant to say, and it didn't accross well in the
        wording...

seb-02  Are there cases where you want to let IPv4 packets with an
        unspecified source through?  The spec doesn't appear to
        address that.

seb-03  Do you verify that SLLA options in ICMPv6 packets match the
        MAC address of the link?



VOTE
====
Approve - Glenn, Gary, Seb, Rick, Garrett, Kais
Deny -
Abstain -
Not Participating (NP) -

THE NEXT STEP
=============
	approved to move forward