From sacadmin Wed Aug 12 08:25:20 2009 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7CFPK9U006118; Wed, 12 Aug 2009 08:25:20 -0700 (PDT) Received: (from kais@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n7CFPKTu006114; Wed, 12 Aug 2009 08:25:20 -0700 (PDT) Date: Wed, 12 Aug 2009 08:25:20 -0700 (PDT) From: Kais Belgaied Message-Id: <200908121525.n7CFPKTu006114@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Subject: Anti-spoofing Link Protection [PSARC/2009/436 OnePager] Status: RO Content-Length: 561 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Anti-spoofing Link Protection 1.2. Name of Document Author/Supplier: Author: Eric Cheng 1.3 Date of This Document: 12 August, 2009 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: OnePager 6.6. ARC Exposure: open From gww@sac.sfbay.sun.com Wed Aug 19 11:34:36 2009 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7JIYa3X015238; Wed, 19 Aug 2009 11:34:36 -0700 (PDT) Received: (from gww@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n7JIYa5P015237; Wed, 19 Aug 2009 11:34:36 -0700 (PDT) Date: Wed, 19 Aug 2009 11:34:36 -0700 (PDT) From: Gary Winiger Message-Id: <200908191834.n7JIYa5P015237@sac.sfbay.sun.com> To: PSARC-ext@sac.sfbay.sun.com, kais.belgaied@sun.com Cc: eric.cheng@sun.com Subject: Re: Anti-spoofing Link Protection [PSARC/2009/436] Status: RO Content-Length: 393 > gw-1 What's the administrative interface? dladm? What's the policy for setting these properties? Eric and I were going to resolve any issues with the policy for these properties offline. Since the meeting I've done the research I hadn't gotten to. dladm is contained in the Network Management Rights Profile with appropriate privilege to make they necessary system calls. Gary.. From Kais.Belgaied@sun.com Wed Aug 26 09:57:48 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n7QGvllC015709 for ; Wed, 26 Aug 2009 09:57:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n7QGvcXa014149 for <@sunmail2sca.sfbay.sun.com:psarc-ext@Sun.COM>; Thu, 27 Aug 2009 00:57:46 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KOZ00G03TS8II00@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 26 Aug 2009 09:57:44 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.59]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KOZ00DQLTS7WB30@nwk-avmta-2.sfbay.sun.com> for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Wed, 26 Aug 2009 09:57:43 -0700 (PDT) Received: from [129.146.11.144] (sr1-jurassic-01.SFBay.Sun.COM [129.146.11.144]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n7QGvhmX670255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Aug 2009 09:57:43 -0700 (PDT) Date: Wed, 26 Aug 2009 09:57:43 -0700 From: Kais Belgaied Subject: Opinion for PSARC review - PSARC/2009/436 Anti-spoofing Link Protection To: psarc-ext@sun.com Message-id: <4A956987.4040100@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_hhglBfpHy3FF8A4I4i/t6g)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 4020 This is a multi-part message in MIME format. --Boundary_(ID_hhglBfpHy3FF8A4I4i/t6g) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT The project's modified doc per requested spec updates is in the finals.materials of the case directory. Attached is the opinion for PSARC review by 09/03/2009. Kais. http://blogs.sun.com/kais --Boundary_(ID_hhglBfpHy3FF8A4I4i/t6g) Content-type: text/plain; name=opinion.ascii Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.ascii Sun Microsystems Systems Architecture Committee _________________________________________________________________ Subject: Anti-spoofing Link Protection Submitted by: Eric Cheng File: PSARC/2009/436/opinion.txt Date: August 19th, 2009. Committee: Kais Belgaied, Garrett D'Amore, Richard Matthews, Sebastien Roy, Glenn Skinner, Gary Winiger Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary 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 neighbors 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. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of Solaris. 3. Interfaces Interfaces Exported Interface Classification Comments protection, Uncommitted new link properties allowed-ips, allowed-dhcp-cids kstats Volatile net:::mac:mac_spoofed, net:::mac:ip_spoofed, net:::mac:dhcp_spoofed, net:::mac:restricted 4. Opinion 4.1. Loss of credentials of message senders A couple of members raised the issue in the Solaris kernel of the non-attributability of some of the events related to attempts to violate the L2 anti-spoofing policies. The issue is affects all events that happens after a packet processing gets dissociated from its generating user thread (aka asynchronous processing), and is common to other parts of the networking stack. It was noted that the issue prevents from generating accurate audit records for accountability and serviceability. The only action was to assert that as a minimum, proper counters for the violation are incremented in this case. 4.2. Unspecified addresses The project specifications were not clear on the expected behavior when it comes to filtering packets destined to the unspecified IP address (all zeros). That led to a discussion in particular about the two possible cases with and without dhcp-nospoof included in the protection property. The discussion converged to a spec update explicitly describing the expected behavior. 4.3 No-spoof ON by default for zones Committee members felt that the setting of the L2 protection property can be a powerful security feature especially for zones. They recommended that the project team considers a better integration with zonecfg, allowing the protection to be turned on by default at zone creation time. Given the extent and possible consequences from such default behavior modifications, the recommendation did not evolve to any advice for a technical change. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material PSARC/2009/436/final.materials/link_protect.txt PSARC/2009/436 Copyright 2009 Sun Microsystems --Boundary_(ID_hhglBfpHy3FF8A4I4i/t6g)-- From sac-owner Tue Sep 15 07:34:41 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n8FEYfit007995 for ; Tue, 15 Sep 2009 07:34:41 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n8FEYZJJ063958 for <@sunmail2sca.sfbay.sun.com:sac-review@Sun.COM>; Tue, 15 Sep 2009 08:34:41 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KQ000B1YOHSCC00@nwk-avmta-1.sfbay.Sun.COM> for sac-review@Sun.COM (ORCPT sac-review@Sun.COM); Tue, 15 Sep 2009 07:34:40 -0700 (PDT) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KQ00080BOHR0L60@nwk-avmta-1.sfbay.Sun.COM> for sac-review@Sun.COM (ORCPT sac-review@Sun.COM); Tue, 15 Sep 2009 07:34:39 -0700 (PDT) Received: from [129.146.11.144] (sr1-jurassic-01.SFBay.Sun.COM [129.146.11.144]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n8FEYdIN327253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Sep 2009 07:34:39 -0700 (PDT) Date: Tue, 15 Sep 2009 07:34:39 -0700 From: Kais Belgaied Subject: Opinion for SAC review 2009/436 Anti-spoofing Link Protection To: sac-review@sun.com Message-id: <4AAFA5FF.7020401@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_iZnDWfGoz/SLvY7ojCzy8A)" X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.21 (X11/20090311) Status: RO Content-Length: 3886 This is a multi-part message in MIME format. --Boundary_(ID_iZnDWfGoz/SLvY7ojCzy8A) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT Please review the attached opinion by Sept 22nd, 2009 Kais. --Boundary_(ID_iZnDWfGoz/SLvY7ojCzy8A) Content-type: text/plain; name=opinion.ascii Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.ascii Sun Microsystems Systems Architecture Committee _________________________________________________________________ Subject: Anti-spoofing Link Protection Submitted by: Eric Cheng File: PSARC/2009/436/opinion.txt Date: August 19th, 2009. Committee: Kais Belgaied, Garrett D'Amore, Richard Matthews, Sebastien Roy, Glenn Skinner, Gary Winiger Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary 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 neighbors 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. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of Solaris. 3. Interfaces Interfaces Exported Interface Classification Comments protection, Uncommitted new link properties allowed-ips, allowed-dhcp-cids kstats Volatile net:::mac:mac_spoofed, net:::mac:ip_spoofed, net:::mac:dhcp_spoofed, net:::mac:restricted 4. Opinion 4.1. Loss of credentials of message senders A couple of members raised the issue in the Solaris kernel of the non-attributability of some of the events related to attempts to violate the L2 anti-spoofing policies. The issue is affects all events that happens after a packet processing gets dissociated from its generating user thread (aka asynchronous processing), and is common to other parts of the networking stack. It was noted that the issue prevents from generating accurate audit records for accountability and serviceability. The only action was to assert that as a minimum, proper counters for the violation are incremented in this case. 4.2. Unspecified addresses The project specifications were not clear on the expected behavior when it comes to filtering packets destined to the unspecified IP address (all zeros). That led to a discussion in particular about the two possible cases with and without dhcp-nospoof included in the protection property. The discussion converged to a spec update explicitly describing the expected behavior. 4.3 No-spoof ON by default for zones Committee members felt that the setting of the L2 protection property can be a powerful security feature especially for zones. They recommended that the project team considers a better integration with zonecfg, allowing the protection to be turned on by default at zone creation time. Given the extent and possible consequences from such default behavior modifications, the recommendation did not evolve to any advice for a technical change. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material PSARC/2009/436/final.materials/link_protect.txt PSARC/2009/436 Copyright 2009 Sun Microsystems --Boundary_(ID_iZnDWfGoz/SLvY7ojCzy8A)-- From sac-owner Tue Oct 27 18:31:07 2009 Received: from jurassic-x4600.sfbay.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n9S1V7Ml021922 for ; Tue, 27 Oct 2009 18:31:07 -0700 (PDT) Received: from [129.146.11.144] (sr1-jurassic-01.SFBay.Sun.COM [129.146.11.144]) by jurassic-x4600.sfbay.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n9S1V7pf280676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 27 Oct 2009 18:31:07 -0700 (PDT) Message-ID: <4AE79EDA.8060207@Sun.COM> Date: Tue, 27 Oct 2009 18:31:06 -0700 From: Kais Belgaied User-Agent: Thunderbird 2.0.0.21 (X11/20090311) MIME-Version: 1.0 To: sac-opinion@sac.sfbay.sun.com Subject: Opinion for archiving - PSARC/2009/436 Anti-spoofing Link Protection Content-Type: multipart/mixed; boundary="------------010001030401080202020907" Status: RO Content-Length: 3824 This is a multi-part message in MIME format. --------------010001030401080202020907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------010001030401080202020907 Content-Type: text/plain; name="opinion.ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="opinion.ascii" Sun Microsystems Systems Architecture Committee _________________________________________________________________ Subject: Anti-spoofing Link Protection Submitted by: Eric Cheng File: PSARC/2009/436/opinion.txt Date: August 19th, 2009. Committee: Kais Belgaied, Garrett D'Amore, Richard Matthews, Sebastien Roy, Glenn Skinner, Gary Winiger Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary 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 neighbors 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. 2. Decision & Precedence Information The project is approved as specified in reference [1]. The project may be delivered in a patch release of Solaris. 3. Interfaces Interfaces Exported Interface Classification Comments protection, Uncommitted new link properties allowed-ips, allowed-dhcp-cids kstats Volatile net:::mac:mac_spoofed, net:::mac:ip_spoofed, net:::mac:dhcp_spoofed, net:::mac:restricted 4. Opinion 4.1. Loss of credentials of message senders A couple of members raised the issue in the Solaris kernel of the non-attributability of some of the events related to attempts to violate the L2 anti-spoofing policies. The issue is affects all events that happens after a packet processing gets dissociated from its generating user thread (aka asynchronous processing), and is common to other parts of the networking stack. It was noted that the issue prevents from generating accurate audit records for accountability and serviceability. The only action was to assert that as a minimum, proper counters for the violation are incremented in this case. 4.2. Unspecified addresses The project specifications were not clear on the expected behavior when it comes to filtering packets destined to the unspecified IP address (all zeros). That led to a discussion in particular about the two possible cases with and without dhcp-nospoof included in the protection property. The discussion converged to a spec update explicitly describing the expected behavior. 4.3 No-spoof ON by default for zones Committee members felt that the setting of the L2 protection property can be a powerful security feature especially for zones. They recommended that the project team considers a better integration with zonecfg, allowing the protection to be turned on by default at zone creation time. Given the extent and possible consequences from such default behavior modifications, the recommendation did not evolve to any advice for a technical change. 5. Minority Opinion(s) None. 6. Advisory Information None. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material PSARC/2009/436/final.materials/link_protect.txt PSARC/2009/436 Copyright 2009 Sun Microsystems --------------010001030401080202020907--