From jmh@joelhalpern.com Sat Feb 23 14:24:34 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D789C21F8DDC; Sat, 23 Feb 2013 14:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.263 X-Spam-Level: X-Spam-Status: No, score=-102.263 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ml5HELr8htXB; Sat, 23 Feb 2013 14:24:34 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id F2F8921F8D96; Sat, 23 Feb 2013 14:24:33 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id C1EB8A68DC; Sat, 23 Feb 2013 14:24:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 99EC81C090F; Sat, 23 Feb 2013 14:24:30 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-91.clppva.east.verizon.net [70.106.135.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E532A1C0539; Sat, 23 Feb 2013 14:24:27 -0800 (PST) Message-ID: <5129418E.5060502@joelhalpern.com> Date: Sat, 23 Feb 2013 17:24:14 -0500 From: Joel Halpern User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: david.black@emc.com References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <4DCD4DEA.2050902@joelhalpern.com> <7C4DFCE962635144B8FAE8CA11D0BF1E055F6937FA@MX14A.corp.emc.com> <4DD142AE.5030409@joelhalpern.com> <7C4DFCE962635144B8FAE8CA11D0BF1E055F693A04@MX14A.corp.emc.com> <4DD15A40.2010209@joelhalpern.com> In-Reply-To: <4DD15A40.2010209@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: savi@ietf.org, gen-art@ietf.org, Russ Housley , christian.vogt@ericsson.com, jeanmichel.combes@gmail.com, joel.halpern@ericsson.com Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05 X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 22:24:35 -0000 Antiquity lives on. This draft is back from the dead. Somehow, it made it to the IESG review without my finishing addressing your comments. My apologies for that. I am trying to finish this off. You will see Monday afternoon a new draft in the repository, with a section 4.1.2 on LACP, and a new paragraph in 5.2.3 to note the issues around (virtual) host relocation. I hope that these properly address your old but very well-taken comments. (I can send it to you if you want itsooner.) Thank you, Joel M. Halpern On 5/16/2011 1:09 PM, Joel M. Halpern wrote: > I can plan to make these changes at the end of the last call. > Joel > > On 5/16/2011 12:56 PM, david.black@emc.com wrote: >> Joel, >> >> I think the LACP discussion could be added to 4.1.1. >> >> I also think that there's a general theme that needs to be covered >> across all of 4.1.1 - 4.1.4: When there are multiple traffic egress >> points from a domain (4.1.1 - 4.1.4 cover four different types of >> domains), the SAVI checks on all the egresses should be coordinated >> and consistent in order to avoid surprises when the traffic switches >> to a different egress point. >> >> Thanks, >> --David >> >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Monday, May 16, 2011 11:29 AM >>> To: Black, David >>> Cc: dmcpherson@verisign.com; fred@cisco.com; >>> joel.halpern@ericsson.com; gen-art@ietf.org; >>> savi@ietf.org; christian.vogt@ericsson.com; jeanmichel.combes@gmail.com >>> Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05 >>> >>> Looking at the draft more carefully (when I am more awake, sorry), I >>> think what you are asking is that more text be put in section 4.1, maybe >>> a subsection? That additional text would talk about placement on a >>> switch that is not directly attached to the client, but is not as far >>> upstream as the first hop router? That text would include mention of >>> the effect of spanning tree variation and LACP path changes. >>> >>> Sorry I was dense, >>> Joel >>> >>> On 5/15/2011 9:45 PM, david.black@emc.com wrote: >>>> Joel, >>>> >>>> If LACP is running active-passive across links to two different >>>> switches, there may be no physical >>> network node common to the currently active and currently passive >>> paths for some traffic. If SAVI >>> is set up poorly, a switch to the currently passive link could remove >>> validation checks or black- >>> hole traffic that was flowing on the previously active link. For >>> example, binding an IP address to a >>> single port or ports on a single switch is insufficient in such an >>> environment (address validation >>> binding needs to span switches). >>>> >>>> The material in 5.2.4 on Multi-LAN Hosts looks like a starting point >>>> - wrt SAVI, active-passive >>> link aggregation across multiple switches can be a way to get into >>> that sort of trouble on a single >>> LAN (!). Beyond that, I think the notion that SAVI checks should be >>> consistent across alternate >>> paths for the same traffic is applicable at other scopes, e.g., all >>> egresses from a multi-homed >>> network to the ISP networks involved. >>>> >>>> Thanks, >>>> --David >>>> >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: Friday, May 13, 2011 11:28 AM >>>>> To: Black, David >>>>> Cc: dmcpherson@verisign.com; fred@cisco.com; >>>>> joel.halpern@ericsson.com; gen-art@ietf.org; >>>>> savi@ietf.org; christian.vogt@ericsson.com; >>>>> jeanmichel.combes@gmail.com >>>>> Subject: Re: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05 >>>>> >>>>> Thank you David. >>>>> I think I understand the second part of your comment (about >>>>> multi-instance hosts), and will have to look at the document more >>>>> to see >>>>> how to address that. >>>>> >>>>> I am not sure I understand what the question is regarding the LACP / >>>>> link group issue. Is this really different from the issues that arise >>>>> whenever the SAVI functionality is not on the leaf switch? Where >>>>> in the >>>>> document do you think it would help to discuss this? >>>>> >>>>> Thank you, >>>>> Joel >>>>> >>>>> On 5/13/2011 1:03 AM, david.black@emc.com wrote: >>>>>> I am the assigned Gen-ART reviewer for this draft. For background on >>>>>> Gen-ART, please see the FAQ at >>>>>> . >>>>>> >>>>>> Please resolve these comments along with any other Last Call comments >>>>>> you may receive. >>>>>> >>>>>> Document: draft-ietf-savi-threat-scope-05 >>>>>> Reviewer: David L. Black >>>>>> Review Date: 12 May 2011 >>>>>> IETF LC End Date: 18 May 2011 >>>>>> >>>>>> Summary: This draft is on the right track, but has open issues, >>>>>> described in the review. >>>>>> >>>>>> This draft discusses the threats and deployment environment for IP >>>>>> source >>>>>> address validation with particular attention to finer-grain >>>>>> validation that >>>>>> could be used within a network to validate IP addresses closer to >>>>>> the sources >>>>>> of network traffic than ingress to an ISP's network. >>>>>> >>>>>> Major issues: >>>>>> >>>>>> There is no discussion of link teaming or aggregation (e.g., via >>>>>> LACP); this >>>>>> may affect source address validation functionality by requiring >>>>>> the same >>>>>> validation checks on all aggregated ports. An important case to >>>>>> discuss >>>>>> is where the aggregated host links are connected to ports on >>>>>> different switches >>>>>> (e.g., in an active/passive configuration). >>>>>> >>>>>> The discussion of multi-instance hosts in section 5.2.3 is incomplete >>>>>> in several important aspects: >>>>>> >>>>>> (1) Some of the software switch implementations are single >>>>>> instance switches >>>>>> whose implementation is distributed across multiple physical >>>>>> servers. This >>>>>> results in concerns similar to the link aggregation discussion above. >>>>>> >>>>>> (2) Live migration of virtual machines among physical servers causes >>>>>> relocation of MAC addresses across switch ports. A so-called >>>>>> "gratuitous ARP" >>>>>> is often used to inform the network of the MAC address move; >>>>>> port-based >>>>>> source address validation information needs to move in response to >>>>>> such ARPs. >>>>>> >>>>>> (3) MAC address relocation is also used as a failure recovery >>>>>> technique; the >>>>>> surviving hardware element (e.g., host in a cluster) takes over >>>>>> the MAC >>>>>> addresses of the failed hardware; like the previous case, a >>>>>> "gratuitous ARP" >>>>>> is a common means of informing the network that the MAC address >>>>>> has moved, >>>>>> and source address validation information needs to move in >>>>>> response to it. >>>>>> >>>>>> Minor issues: >>>>>> >>>>>> There doesn't seem to be much discussion of dynamic network >>>>>> reconfiguration, >>>>>> which may change traffic egress points. VRRP may be a useful >>>>>> example to >>>>>> discuss beyond the typical routing protocol updates to forwarding >>>>>> tables. >>>>>> >>>>>> Nits/editorial comments: >>>>>> >>>>>> idnits 2.12.11 ran clean. >>>>>> >>>>>> Thanks, >>>>>> --David >>>>>> ---------------------------------------------------- >>>>>> David L. Black, Distinguished Engineer >>>>>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>>>>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>>>>> david.black@emc.com Mobile: +1 (978) 394-7754 >>>>>> ---------------------------------------------------- >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> >>>> >>>> >> >> From internet-drafts@ietf.org Mon Feb 25 12:13:47 2013 Return-Path: X-Original-To: savi@ietfa.amsl.com Delivered-To: savi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D30D21F9457; Mon, 25 Feb 2013 12:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOa-XFtq2l2g; Mon, 25 Feb 2013 12:13:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9183821F9239; Mon, 25 Feb 2013 12:12:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225201256.27545.46492.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 12:12:56 -0800 Cc: savi@ietf.org Subject: [savi] I-D Action: draft-ietf-savi-threat-scope-06.txt X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Mailing list for the SAVI working group at IETF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 20:13:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Source Address Validation Improvements Wo= rking Group of the IETF. Title : SAVI Threat Scope Author(s) : Danny McPherson Fred Baker Joel M. Halpern Filename : draft-ietf-savi-threat-scope-06.txt Pages : 25 Date : 2013-02-25 Abstract: Source Address Validation Improvement (SAVI) effort aims to complement ingress filtering with finer-grained, standardized IP source address validation. This document describes threats enabled by IP source address spoofing both in the global and finer-grained context, describes currently available solutions and challenges, and provides a starting point analysis for finer-grained (host granularity) anti-spoofing work. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-savi-threat-scope-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-savi-threat-scope-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/