From jari.arkko@piuha.net Wed May 4 02:13:27 2011 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 025F2E06EF for ; Wed, 4 May 2011 02:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 T4wNhnuHCSVk for ; Wed, 4 May 2011 02:13:26 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id D7544E06C5 for ; Wed, 4 May 2011 02:13:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 95F792D35A; Wed, 4 May 2011 12:13:17 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pRBN+G6wLFE; Wed, 4 May 2011 12:13:16 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 85B782CC49; Wed, 4 May 2011 12:13:16 +0300 (EEST) Message-ID: <4DC118AB.90001@piuha.net> Date: Wed, 04 May 2011 11:13:15 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: SAVI Mailing List , draft-ietf-savi-threat-scope@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [savi] AD review of draft-ietf-savi-threat-scope 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: Wed, 04 May 2011 09:13:27 -0000 I have reviewed this draft. It is a very well written document and I have sent it forward to an IETF last call. I did have a few issues, however, and I would like to ask the authors to take a look during the last call and issue a new revision if they think it is appropriate: > This both that the information be useable (logging), and that the > information be accurate, i.e. that no other machine could have been > using that address. > There is something odd in this sentence. > Furthermore, BCP 38 only implies source address > verification at the Internet Layer, and is most often implemented on > IP subnetwork address boundaries. maybe "... solely at the Internet layer ...." > For example, Internet > devices can confirm that: > > o The IP source address is appropriate for the lower layer address > (they both identify the same system) > > o The IP source address is appropriate for the device at the layer 2 > switch port (the address was assigned to a, and perhaps the, > system that uses that port) > > For example, a device that has > an authoritative table between Link Layer and IP addresses on a link > can discard any datagrams in which the IP address is not associated > with the Link Layer address in the datagram. I think it is important to already here acknowledge the fact that the mappings are not as straightforward as one might think. For instance, you could make this change: s/The IP source address is appropriate for the lower layer address (they both identify the same system). Naturally, reliance on such a check requires the ability track what the correct address mappings are, including hosts with multiple addresses and other complications." > However, two primary areas exist that > can complicate such techniques. In particular, these areas involve > topologies where more than a single IP layer address may be > associated with a MAC address on a given port, or where multiple > hosts are connected via a single physical port. Furthermore, if one > or more dynamic address allocation mechanisms such as DHCP are > employed, then some mechanism must exist to associate those IP layer > addresses with the appropriate Link layer ports, as addresses are > allocated or reclaimed. > I would think that the third area is movements between ports (e.g., due to a wireless host moving from one AP to another) > It should be understood that not all combinations of network, service > and enforcement choices will result in a protectable network. For > example, if one uses conventional SLAAC, in a switched network, but > tries to only provide address enforcement on the routers on the > network, then the ability to provide protection is severely limited. > I think you could make an even stronger statement here. "If one has a switched network of hosts, but tries to only provide address enforcement on the routers on the network, ..." > The most obvious example of devices that are problematic when > attempting to implement port-MAC-IP bindings is that of routers. > Routers not only originate packets themselves and often have multiple > interfaces, but also forward packets from other network segments. As > a result, it's difficult for port-MAC-IP binding rules to be > established a priori, because it's likely that many addresses and IP > subnets should be associated with the port-MAC in question. > You might want to note that there are exceptional cases, such as prefix delegation where this knowledge is available. > may forward traffic from an array of address addresses > 5.2.6. Mobile IP > > > Mobile IP hosts in both IPv4 and IPv6 are proper members I would generalize this to 5.2.6 Mobile hosts, keep the original text, but add at the front some discussion of hosts that move around. This too is an important case. Jari From iesg-secretary@ietf.org Wed May 4 06:17:12 2011 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 114B7E078E; Wed, 4 May 2011 06:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.044 X-Spam-Level: X-Spam-Status: No, score=-102.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 RAQUYhKYEHdh; Wed, 4 May 2011 06:17:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F5FE06A4; Wed, 4 May 2011 06:17:11 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110504131711.28643.81970.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 06:17:11 -0700 X-Mailman-Approved-At: Wed, 04 May 2011 09:33:45 -0700 Cc: savi@ietf.org Subject: [savi] Last Call: (SAVI Threat Scope) to Informational RFC X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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: Wed, 04 May 2011 13:17:12 -0000 The IESG has received a request from the Source Address Validation Improvements WG (savi) to consider the following document: - 'SAVI Threat Scope' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-05-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-savi-threat-scope/ No IPR declarations have been submitted directly on this I-D. From jari.arkko@piuha.net Wed May 4 11:41:35 2011 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 BCDB0E07AE for ; Wed, 4 May 2011 11:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 aX3YejgX2OvA for ; Wed, 4 May 2011 11:41:35 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE49E0795 for ; Wed, 4 May 2011 11:41:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 12F2B2D35A; Wed, 4 May 2011 21:41:27 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoTye0Bwk55z; Wed, 4 May 2011 21:41:25 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 79C742CC49; Wed, 4 May 2011 21:41:25 +0300 (EEST) Message-ID: <4DC19DD5.4040209@piuha.net> Date: Wed, 04 May 2011 20:41:25 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-savi-fcfs@tools.ietf.org, SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [savi] AD review of draft-ietf-savi-fcfs 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: Wed, 04 May 2011 18:41:35 -0000 I have reviewed this draft. The specification is well written, and while it took an entire day for me to be (relatively) convinced that the state machine is correct, it is easy to read. I have sent the draft forward to an IETF last call. However, I did have a few suggestions and questions that I hope you can treat and if needed, issue a new draft version. > Neighbour Solicitation (NSOL) > and Neighbour Advertisement (NADV) messages Can we use the usual abbreviations, NS and NA? > Router Advertisement: A SAVI device MUST support discovery of on-link > prefixes through Router Advertisement messages. The SAVI device will > learn the on-link prefixes following the procedure defined for a host > to process the Prefix Information options described in section 6.3.4 > of [RFC4861] with the difference that the prefixes will be configured > in the FCFS SAVI Prefix List rather than in the ND Prefix List. In > addition, when the SAVI device boots, it MUST send a Router > Solicitation message as described in section 6.3.7 of [RFC4861] , > using the unspecified source address. > Will this process be run on all ports, or just the trusted ones? Please specify. > o If the data packet is received through a Validating port, then the > SAVI function checks whether the received data packet is local > traffic or transit traffic. It does so by verifying if the source > address of the packet belongs to one of the directly connected > prefixes available in the receiving interface. It does so by > searching the FCFS SAVI Prefix List. > * If the IP source address does not belong to one of the local > prefixes of the receiving interface, this means that the data > packet is transit traffic and the packet SHOULD be discarded. > You need to add a special case for supporting the unspecified address. > This may due to an attack or to the fact that the host > may have moved. ... may be due to an ... > and 250 millisconds later Milliseconds. And please put the value to a constant in a separate section. > The DAD_NSOL messages are sent > through the proper Trusted Ports (as defined by the switch > behaviour that will depend on whether it performs MLD snooping or > not). The word "proper" is confusing here. How about this text instead: The DAD_NSOL messages are sent through Trusted Ports (but of course subject to usual switch behavior and possible MLD snooping optimizations). > the SAVI device MUST forward the NSOL and 250 > millisconds later it MUST execute the process of sending Neighbour > Solicitation messages This could be clearer. First, you forward the NSOL completely normally. Then you separately run the NS process *on behalf of the host*, but forward these NSOL messages only to TP ports. Correct? A couple of questions, however. What's the source MAC address in such packets, the host's or the switch's address? And why aren't you simply copying the same message, separated by X ms? Finally, are you forwarding one message and generating two copies, altogether three messages? Additional clarity here would be useful. > o DAD_NSOL packets containing IPAddr as the target address received > through a Trusted port are NOT forwarded through any of the > Validating ports but they are sent through the proper Trusted > Ports (as defined by the switch behaviour that will depend on > whether it performs MLD snooping or not) > I don't understand why these messages are only forwardded to the TPs. > o Neighbor Advertisement packets sent to all nodes as a reply to the > DAD_NSOL (hereafter called DAD_NADV) containing IPAddr as the > target address coming through a Validating port are discarded. > This seems to break the principle of SAVI not changing network behavior except where a delay is necessary while you verify something. Why is it necessary to not forward these messages as they normally are forwarded through the network? > So, when SEND is deployed, it is recommended to use SEND SAVI > [I-D.ietf-savi-send ] rather than FCFS SAVI." > Is there some reason why proxy SEND cannot be employed here? Jari From nordmark@acm.org Wed May 4 15:55:20 2011 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 3F842E06C7 for ; Wed, 4 May 2011 15:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 SjxGAl8UteQu for ; Wed, 4 May 2011 15:55:19 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id CA722E06BF for ; Wed, 4 May 2011 15:55:19 -0700 (PDT) Received: from [128.107.115.230] ([128.107.115.230]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p44MtFXB016907 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 4 May 2011 15:55:15 -0700 Message-ID: <4DC1D953.4020207@acm.org> Date: Wed, 04 May 2011 15:55:15 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jari Arkko References: <4DC19DD5.4040209@piuha.net> In-Reply-To: <4DC19DD5.4040209@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-savi-fcfs@tools.ietf.org, SAVI Mailing List Subject: Re: [savi] AD review of draft-ietf-savi-fcfs 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: Wed, 04 May 2011 22:55:20 -0000 On 5/4/11 11:41 AM, Jari Arkko wrote: >> So, when SEND is deployed, it is recommended to use SEND SAVI >> [I-D.ietf-savi-send >> ] >> rather than FCFS SAVI." > > Is there some reason why proxy SEND cannot be employed here? Proxy send assumes that the host is aware of the proxy, since the way the packets are authenticated are different. Thus while proxy send is useful for e.g., MIP HAs, it doesn't help for something which needs to work with basic SeND. Erik From jari.arkko@piuha.net Thu May 5 00:36:41 2011 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 AB44BE071B for ; Thu, 5 May 2011 00:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 DvfSFY+5pgTD for ; Thu, 5 May 2011 00:36:41 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id CCB24E0704 for ; Thu, 5 May 2011 00:36:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id E6A192CC49; Thu, 5 May 2011 10:36:39 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo9IN-0mHSbO; Thu, 5 May 2011 10:36:39 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 6359B2CC2F; Thu, 5 May 2011 10:36:39 +0300 (EEST) Message-ID: <4DC25387.3080208@piuha.net> Date: Thu, 05 May 2011 09:36:39 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Erik Nordmark References: <4DC19DD5.4040209@piuha.net> <4DC1D953.4020207@acm.org> In-Reply-To: <4DC1D953.4020207@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-savi-fcfs@tools.ietf.org, SAVI Mailing List Subject: Re: [savi] AD review of draft-ietf-savi-fcfs 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: Thu, 05 May 2011 07:36:41 -0000 Erik, > Proxy send assumes that the host is aware of the proxy, since the way > the packets are authenticated are different. > > Thus while proxy send is useful for e.g., MIP HAs, it doesn't help for > something which needs to work with basic SeND. Ok. Can this be stated in the draft? Jari From jeanmichel.combes@gmail.com Thu May 5 01:34:32 2011 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 12A35E06FE for ; Thu, 5 May 2011 01:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 zQrh41KRRgME for ; Thu, 5 May 2011 01:34:30 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9C17DE0693 for ; Thu, 5 May 2011 01:34:30 -0700 (PDT) Received: by gwb20 with SMTP id 20so820551gwb.31 for ; Thu, 05 May 2011 01:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=YLxiUDEKeh62WNEthvqRMh5c7uap6j0LFvVxRm4/FBM=; b=hrZAfEyV3qlBQXY5QL/+aPqXZgqXP4Q0GJJzZ39Ns3a/Ym8A4mi2A81AYE8PaZH19F iV/MIDIuXtW8brFQSr3qz6AQiFADSgA5ev4a1+FCvwE5cvo2Sl3hk6BPW+rLgi6ZaejJ s1v0zAZQdnPTM3j3cuGsy3zL4bd2tOtZBORzo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=oEO878o58kdm7gAZaGIR/idvuBAo4F82/0U+FWEuiVEIeXgvVbjclC19mcZaf8GRfq A76hkE3LqLxX3JSW5eNXyzIhjKB+LBzyQNyZRVnhjapuZE1eHBaq4Ibcu0kAb5pGCgMu M6Dmfw3IItTS/bUPu71z2xcUyrFCDt+8W2iAY= MIME-Version: 1.0 Received: by 10.150.251.29 with SMTP id y29mr1998295ybh.181.1304584469919; Thu, 05 May 2011 01:34:29 -0700 (PDT) Received: by 10.147.171.17 with HTTP; Thu, 5 May 2011 01:34:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 5 May 2011 10:34:29 +0200 Message-ID: From: Jean-Michel Combes To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [savi] Adoption of "SAVI for Mixed Address Assignment Methods Scenario" (draft-bi-savi-mix-04) as WG I-D: confirmation? 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: Thu, 05 May 2011 08:34:32 -0000 Hi, As: (1) there are no concerns about the adoption of "SAVI for Mixed Address Assignment Methods Scenario" document as WG document (2) such a document is now officially inside the milestones list (cf. http://tools.ietf.org/wg/savi/charters?item=charter-savi-2011-05-04.txt) a new version of the document can be submitted as WG draft. Best regards. JMC. 2011/4/6 Jean-Michel Combes : > Folks, > > during the last SAVI meeting in Prague, there was a consensus to adopt > "SAVI for Mixed Address Assignment Methods Scenario" document > (draft-bi-savi-mix-04) as WG document. > > If you have any concern about this adoption, please send an email on > the ML before next Tuesday. > > Best regards. > > JMC. > From iesg-secretary@ietf.org Wed May 4 11:50:51 2011 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 954F9E07C8; Wed, 4 May 2011 11:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.468 X-Spam-Level: X-Spam-Status: No, score=-102.468 tagged_above=-999 required=5 tests=[AWL=0.131, 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 omz98o6yMPwd; Wed, 4 May 2011 11:50:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE9EE06C7; Wed, 4 May 2011 11:50:50 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110504185050.4826.96357.idtracker@ietfa.amsl.com> Date: Wed, 04 May 2011 11:50:50 -0700 X-Mailman-Approved-At: Thu, 05 May 2011 08:43:08 -0700 Cc: savi@ietf.org Subject: [savi] Last Call: (FCFS SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned IPv6 Addresses) to Proposed Standard X-BeenThere: savi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org 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: Wed, 04 May 2011 18:50:51 -0000 The IESG has received a request from the Source Address Validation Improvements WG (savi) to consider the following document: - 'FCFS SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned IPv6 Addresses' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-05-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-savi-fcfs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-savi-fcfs/ No IPR declarations have been submitted directly on this I-D. From joel.halpern@ericsson.com Thu May 5 08:22:12 2011 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 A8BCFE08A4 for ; Thu, 5 May 2011 08:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 32dXPSbIwQnK for ; Thu, 5 May 2011 08:22:12 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id 18A7DE0790 for ; Thu, 5 May 2011 08:22:11 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p45FM9KW031771; Thu, 5 May 2011 10:22:11 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Thu, 5 May 2011 11:22:05 -0400 From: Joel Halpern To: Jari Arkko , SAVI Mailing List Date: Thu, 5 May 2011 11:22:05 -0400 Thread-Topic: AD review of draft-ietf-savi-threat-scope Thread-Index: AcwKO4se5kJcW8XlTDyxPMsvtfn3swA/HA+w Message-ID: <49044C2B7F64814BAA8D09EA7B8D723212693B9B36@EUSAACMS0701.eamcs.ericsson.se> References: <4DC118AB.90001@piuha.net> In-Reply-To: <4DC118AB.90001@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 05 May 2011 08:43:08 -0700 Subject: Re: [savi] AD review of draft-ietf-savi-threat-scope 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: Thu, 05 May 2011 15:22:12 -0000 Almost all of these suggests (elided) look helpful and actionable. I will = do as you suggest. However, I am not sure what to actually do with the last one. Yours, Joel -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Wednesday, May 04, 2011 5:13 AM To: SAVI Mailing List; draft-ietf-savi-threat-scope@tools.ietf.org Subject: AD review of draft-ietf-savi-threat-scope ... > 5.2.6. Mobile IP > > > Mobile IP hosts in both IPv4 and IPv6 are proper members I would generalize this to 5.2.6 Mobile hosts, keep the original text, but = add at the front some discussion of hosts that move around. This too is an = important case. Jari From Internet-Drafts@ietf.org Thu May 5 12:45:03 2011 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 AA940E0719; Thu, 5 May 2011 12:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 0d7qC3WkWxxI; Thu, 5 May 2011 12:45:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D48E079A; Thu, 5 May 2011 12:45:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110505194503.2464.73611.idtracker@ietfa.amsl.com> Date: Thu, 05 May 2011 12:45:03 -0700 Cc: savi@ietf.org Subject: [savi] I-D ACTION:draft-ietf-savi-dhcp-09.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: Thu, 05 May 2011 19:45:03 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Address Validation Improvements Working Group of the IETF. Title : SAVI Solution for DHCP Author(s) : J. Wu, et al Filename : draft-ietf-savi-dhcp-09.txt Pages : 22 Date : 2011-04-28 This document specifies the procedure for creating bindings between a DHCPv4 [RFC2131]/DHCPv6 [RFC3315] assigned source IP address and a binding anchor [I-D.ietf-savi-framework] on SAVI (Source Address Validation Improvements) device. The bindings can be used to filter packets generated on the local link with forged source IP address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-dhcp-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-savi-dhcp-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-05124118.I-D@ietf.org> --NextPart-- From nordmark@acm.org Thu May 5 15:30:15 2011 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 81BA6E08B8 for ; Thu, 5 May 2011 15:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.099 X-Spam-Level: X-Spam-Status: No, score=-104.099 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 rektLnLm5aV1 for ; Thu, 5 May 2011 15:30:15 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id F2708E0813 for ; Thu, 5 May 2011 15:30:01 -0700 (PDT) Received: from [10.0.1.6] (128-107-239-233.cisco.com [128.107.239.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p45MTvkK009235 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 5 May 2011 15:29:58 -0700 Message-ID: <4DC324E4.3010206@acm.org> Date: Thu, 05 May 2011 15:29:56 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jari Arkko References: <4DC19DD5.4040209@piuha.net> <4DC1D953.4020207@acm.org> <4DC25387.3080208@piuha.net> In-Reply-To: <4DC25387.3080208@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-savi-fcfs@tools.ietf.org, SAVI Mailing List Subject: Re: [savi] AD review of draft-ietf-savi-fcfs 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: Thu, 05 May 2011 22:30:15 -0000 On 5/5/11 12:36 AM, Jari Arkko wrote: > Erik, > >> Proxy send assumes that the host is aware of the proxy, since the way >> the packets are authenticated are different. >> >> Thus while proxy send is useful for e.g., MIP HAs, it doesn't help for >> something which needs to work with basic SeND. > > Ok. Can this be stated in the draft? Sure. But shouldn't it belong in an Applicability section in the proxy SeND spec (as well)? Erik From jari.arkko@piuha.net Fri May 6 02:28:32 2011 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 848F1E06FD for ; Fri, 6 May 2011 02:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 JWcsoWflZdjl for ; Fri, 6 May 2011 02:28:32 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id B7B41E06CE for ; Fri, 6 May 2011 02:28:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CCA852CC4B; Fri, 6 May 2011 12:28:30 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16QIpge9Ujgb; Fri, 6 May 2011 12:28:30 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 003FF2CC2F; Fri, 6 May 2011 12:28:29 +0300 (EEST) Message-ID: <4DC3BF3D.1070105@piuha.net> Date: Fri, 06 May 2011 11:28:29 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Joel Halpern References: <4DC118AB.90001@piuha.net> <49044C2B7F64814BAA8D09EA7B8D723212693B9B36@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <49044C2B7F64814BAA8D09EA7B8D723212693B9B36@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List Subject: Re: [savi] AD review of draft-ietf-savi-threat-scope 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: Fri, 06 May 2011 09:28:32 -0000 How about this: 5.2.6. Mobile Hosts Hosts may move around from switch port to another, either due to being physically moved into a different port, or due to roaming to a wireless access point that is attached to a different switch port. These movements cause an address to suddenly appear at a different part of the topology, or even appear to move back and forth between different points. SAVI solutions should be able to deal with such movements. Mobile IP hosts in both IPv4 and IPv6 are proper members ... (text continues as it was) ... Jari From joel.halpern@ericsson.com Fri May 6 08:35:42 2011 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 88DB5E0694 for ; Fri, 6 May 2011 08:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 pazTv5x9yjGU for ; Fri, 6 May 2011 08:35:42 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by ietfa.amsl.com (Postfix) with ESMTP id F26DDE067A for ; Fri, 6 May 2011 08:35:41 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p46FZd4v009880; Fri, 6 May 2011 10:35:41 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.65]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 6 May 2011 11:35:34 -0400 From: Joel Halpern To: Jari Arkko Date: Fri, 6 May 2011 11:35:33 -0400 Thread-Topic: AD review of draft-ietf-savi-threat-scope Thread-Index: AcwL0AB2AjCb2vLySHSx7mqJdrMdQwAMzaUA Message-ID: <49044C2B7F64814BAA8D09EA7B8D723212693BA17A@EUSAACMS0701.eamcs.ericsson.se> References: <4DC118AB.90001@piuha.net> <49044C2B7F64814BAA8D09EA7B8D723212693B9B36@EUSAACMS0701.eamcs.ericsson.se> <4DC3BF3D.1070105@piuha.net> In-Reply-To: <4DC3BF3D.1070105@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SAVI Mailing List Subject: Re: [savi] AD review of draft-ietf-savi-threat-scope 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: Fri, 06 May 2011 15:35:42 -0000 Works for me. Thanks, Joel=20 -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 Sent: Friday, May 06, 2011 5:28 AM To: Joel Halpern Cc: SAVI Mailing List Subject: Re: AD review of draft-ietf-savi-threat-scope How about this: 5.2.6. Mobile Hosts Hosts may move around from switch port to another, either due to being phys= ically moved into a different port, or due to roaming to a wireless access = point that is attached to a different switch port. These movements cause an= address to suddenly appear at a different part of the topology, or even ap= pear to move back and forth between different points. SAVI solutions should= be able to deal with such movements. Mobile IP hosts in both IPv4 and IPv6 are proper members ... (text continue= s as it was) ... Jari From Internet-Drafts@ietf.org Sat May 7 06:45:02 2011 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 BDB0CE06DB; Sat, 7 May 2011 06:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 PvzE0iwM9XXW; Sat, 7 May 2011 06:45:02 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B9BBE06C5; Sat, 7 May 2011 06:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110507134502.16019.16204.idtracker@ietfa.amsl.com> Date: Sat, 07 May 2011 06:45:02 -0700 Cc: savi@ietf.org Subject: [savi] I-D Action:draft-ietf-savi-mix-00.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: Sat, 07 May 2011 13:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Address Validation Improvements Working Group of the IETF. Title : SAVI for Mixed Address Assignment Methods Scenario Author(s) : J. Bi, et al. Filename : draft-ietf-savi-mix-00.txt Pages : 8 Date : 2011-05-06 This document reviews how multiple address discovery methods can coexist in a single SAVI device and collisions are resolved when the same binding entry is discovered by two or more methods. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-mix-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-savi-mix-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-07063128.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon May 9 09:30:04 2011 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 67ABDE0823; Mon, 9 May 2011 09:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 3fmm+7GT-rGo; Mon, 9 May 2011 09:30:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26B9CE0848; Mon, 9 May 2011 09:30:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.53 Message-ID: <20110509163003.30973.88692.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2011 09:30:03 -0700 Cc: savi@ietf.org Subject: [savi] I-D ACTION:draft-ietf-savi-fcfs-09.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, 09 May 2011 16:30:04 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Address Validation Improvements Working Group of the IETF. Title : FCFS SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned IPv6 Addresses Author(s) : E. Nordmark, et al Filename : draft-ietf-savi-fcfs-09.txt Pages : 31 Date : 2011-04-27 This memo describes FCFS SAVI a mechanism to provide source address validation for IPv6 networks using the First-Come First-Serve principle. The proposed mechanism is intended to complement ingress filtering techniques to provide a finer granularity on the control of the source addresses used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-savi-fcfs-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-savi-fcfs-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-05-09091807.I-D@ietf.org> --NextPart-- From david.black@emc.com Thu May 12 22:08:10 2011 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 962D7E0681; Thu, 12 May 2011 22:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 X0aspSjcT--Y; Thu, 12 May 2011 22:08:09 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 8A985E065D; Thu, 12 May 2011 22:08:09 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4D582dm011063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 May 2011 01:08:03 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd04.lss.emc.com [10.254.222.226]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Fri, 13 May 2011 01:07:49 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.221.46.114]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4D55NGf026945; Fri, 13 May 2011 01:05:24 -0400 Received: from mx14a.corp.emc.com ([169.254.1.163]) by mxhub06.corp.emc.com ([128.221.46.114]) with mapi; Fri, 13 May 2011 01:05:23 -0400 From: To: , , , Date: Fri, 13 May 2011 01:03:18 -0400 Thread-Topic: Gen-ART review of draft-ietf-savi-threat-scope-05 Thread-Index: AcwRKxLMGPOwf18pRUizv8st+VLKCw== Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 X-Mailman-Approved-At: Fri, 13 May 2011 08:21:06 -0700 Cc: savi@ietf.org, david.black@emc.com, christian.vogt@ericsson.com, jeanmichel.combes@gmail.com Subject: [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: Fri, 13 May 2011 05:08:10 -0000 I am the assigned Gen-ART reviewer for this draft. For background on=20 Gen-ART, please see the FAQ at=20 . Please resolve these comments along with any other Last Call comments=20 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 i= n 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 sourc= es of network traffic than ingress to an ISP's network.=20 Major issues: There is no discussion of link teaming or aggregation (e.g., via LACP); thi= s 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 swit= ches (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 switche= s 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=20 relocation of MAC addresses across switch ports. A so-called "gratuitous A= RP" 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 ARP= s. (3) MAC address relocation is also used as a failure recovery technique; th= e 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:=20 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=A0 01748 +1 (508) 293-7953=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 FAX: +1 (508) 293-778= 6 david.black@emc.com=A0=A0=A0=A0=A0=A0=A0 Mobile: +1 (978) 394-7754 ---------------------------------------------------- From jmh@joelhalpern.com Fri May 13 08:27:43 2011 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 093E5E0734; Fri, 13 May 2011 08:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 OSpSqyIboDnR; Fri, 13 May 2011 08:27:42 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 23233E069B; Fri, 13 May 2011 08:27:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 15DF14300BD; Fri, 13 May 2011 08:27:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.131.32.75] (h87.s239.verisign.com [216.168.239.87]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 32C334300B7; Fri, 13 May 2011 08:27:41 -0700 (PDT) Message-ID: <4DCD4DEA.2050902@joelhalpern.com> Date: Fri, 13 May 2011 11:27:38 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: david.black@emc.com References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmcpherson@verisign.com, savi@ietf.org, gen-art@ietf.org, 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: Fri, 13 May 2011 15:27:43 -0000 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 david.black@emc.com Sun May 15 18:46:47 2011 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 ECA74E06D6; Sun, 15 May 2011 18:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.499 X-Spam-Level: X-Spam-Status: No, score=-106.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 jTaGtaTDl2dC; Sun, 15 May 2011 18:46:46 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id B9567E06B9; Sun, 15 May 2011 18:46:46 -0700 (PDT) Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4G1kewN000822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 May 2011 21:46:40 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si02.isus.emc.com (RSA Interceptor); Sun, 15 May 2011 21:46:21 -0400 Received: from mxhub06.corp.emc.com (mxhub06.corp.emc.com [128.221.46.114]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4G1j9pm019266; Sun, 15 May 2011 21:45:09 -0400 Received: from mx14a.corp.emc.com ([169.254.1.163]) by mxhub06.corp.emc.com ([128.221.46.114]) with mapi; Sun, 15 May 2011 21:45:09 -0400 From: To: Date: Sun, 15 May 2011 21:45:02 -0400 Thread-Topic: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05 Thread-Index: AcwRg0p1jkZOw3YkSsSWu6YFhi6ycwANE1IQ Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E055F6937FA@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <4DCD4DEA.2050902@joelhalpern.com> In-Reply-To: <4DCD4DEA.2050902@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: dmcpherson@verisign.com, savi@ietf.org, gen-art@ietf.org, christian.vogt@ericsson.com, jeanmichel.combes@gmail.com, joel.halpern@ericsson.com, david.black@emc.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: Mon, 16 May 2011 01:46:48 -0000 Joel, If LACP is running active-passive across links to two different switches, t= here may be no physical network node common to the currently active and cur= rently 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, bindin= g an IP address to a single port or ports on a single switch is insufficien= t 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 thin= k the notion that SAVI checks should be consistent across alternate paths f= or 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; g= en-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 >=20 > 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. >=20 > 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? >=20 > Thank you, > Joel >=20 > 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, describ= ed in the review. > > > > This draft discusses the threats and deployment environment for IP sour= ce > > address validation with particular attention to finer-grain validation = that > > could be used within a network to validate IP addresses closer to the s= ources > > 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 sam= e > > validation checks on all aggregated ports. An important case to discus= s > > 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 swi= tches > > 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 "gratuito= us 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 mov= ed, > > 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 reconfigura= tion, > > which may change traffic egress points. VRRP may be a useful example t= o > > discuss beyond the typical routing protocol updates to forwarding table= s. > > > > 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 jmh@joelhalpern.com Mon May 16 08:29:06 2011 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 88ADDE071C; Mon, 16 May 2011 08:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 ec9XE4Hm7JmN; Mon, 16 May 2011 08:29:05 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id AD615E06AE; Mon, 16 May 2011 08:29:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 93F6F32479E2; Mon, 16 May 2011 08:29:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.1.4] (pool-173-66-76-136.washdc.fios.verizon.net [173.66.76.136]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 26051325B2B1; Mon, 16 May 2011 08:29:03 -0700 (PDT) Message-ID: <4DD142AE.5030409@joelhalpern.com> Date: Mon, 16 May 2011 11:28:46 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: david.black@emc.com References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <4DCD4DEA.2050902@joelhalpern.com> <7C4DFCE962635144B8FAE8CA11D0BF1E055F6937FA@MX14A.corp.emc.com> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E055F6937FA@MX14A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmcpherson@verisign.com, savi@ietf.org, gen-art@ietf.org, 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: Mon, 16 May 2011 15:29:06 -0000 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 david.black@emc.com Mon May 16 09:57:40 2011 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 CCE90E06B0; Mon, 16 May 2011 09:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.524 X-Spam-Level: X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 uwzMZvmi5QpU; Mon, 16 May 2011 09:57:40 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id E084FE06BB; Mon, 16 May 2011 09:57:39 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4GGvXPC017273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 May 2011 12:57:33 -0400 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Mon, 16 May 2011 12:57:16 -0400 Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com [128.221.46.113]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p4GGuJcf024756; Mon, 16 May 2011 12:56:19 -0400 Received: from mx14a.corp.emc.com ([169.254.1.163]) by mxhub05.corp.emc.com ([128.221.46.113]) with mapi; Mon, 16 May 2011 12:56:19 -0400 From: To: Date: Mon, 16 May 2011 12:56:17 -0400 Thread-Topic: [savi] Gen-ART review of draft-ietf-savi-threat-scope-05 Thread-Index: AcwT3nSkVMnPQZ7nRH2UKPFgBlRwpAACuhlA Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E055F693A04@MX14A.corp.emc.com> References: <7C4DFCE962635144B8FAE8CA11D0BF1E055F69357F@MX14A.corp.emc.com> <4DCD4DEA.2050902@joelhalpern.com> <7C4DFCE962635144B8FAE8CA11D0BF1E055F6937FA@MX14A.corp.emc.com> <4DD142AE.5030409@joelhalpern.com> In-Reply-To: <4DD142AE.5030409@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: dmcpherson@verisign.com, savi@ietf.org, gen-art@ietf.org, christian.vogt@ericsson.com, jeanmichel.combes@gmail.com, joel.halpern@ericsson.com, david.black@emc.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: Mon, 16 May 2011 16:57:40 -0000 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 a= ll of 4.1.1 - 4.1.4: When there are multiple traffic egress points from a d= omain (4.1.1 - 4.1.4 cover four different types of domains), the SAVI check= s on all the egresses should be coordinated and consistent in order to avoi= d 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; g= en-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 >=20 > 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. >=20 > Sorry I was dense, > Joel >=20 > On 5/15/2011 9:45 PM, david.black@emc.com wrote: > > Joel, > > > > If LACP is running active-passive across links to two different switche= s, there may be no physical > network node common to the currently active and currently passive paths f= or some traffic. If SAVI > is set up poorly, a switch to the currently passive link could remove val= idation 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 enviro= nment (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 s= ort of trouble on a single > LAN (!). Beyond that, I think the notion that SAVI checks should be cons= istent across alternate > paths for the same traffic is applicable at other scopes, e.g., all egres= ses 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.co= m > >> 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 s= ee > >> 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 t= he > >> 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, descr= ibed in the review. > >>> > >>> This draft discusses the threats and deployment environment for IP so= urce > >>> address validation with particular attention to finer-grain validatio= n 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 s= ame > >>> validation checks on all aggregated ports. An important case to disc= uss > >>> is where the aggregated host links are connected to ports on differen= t 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 s= witches > >>> 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 "gratui= tous ARP" > >>> is often used to inform the network of the MAC address move; port-bas= ed > >>> source address validation information needs to move in response to su= ch ARPs. > >>> > >>> (3) MAC address relocation is also used as a failure recovery techniq= ue; the > >>> surviving hardware element (e.g., host in a cluster) takes over the M= AC > >>> addresses of the failed hardware; like the previous case, a "gratuito= us ARP" > >>> is a common means of informing the network that the MAC address has m= oved, > >>> and source address validation information needs to move in response t= o it. > >>> > >>> Minor issues: > >>> > >>> There doesn't seem to be much discussion of dynamic network reconfigu= ration, > >>> which may change traffic egress points. VRRP may be a useful example= to > >>> discuss beyond the typical routing protocol updates to forwarding tab= les. > >>> > >>> 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 jmh@joelhalpern.com Mon May 16 10:09:24 2011 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 319F3E0784; Mon, 16 May 2011 10:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 5XVrxEzx0wrI; Mon, 16 May 2011 10:09:23 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 4D321E074A; Mon, 16 May 2011 10:09:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 1C44F3254008; Mon, 16 May 2011 10:09:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.1.4] (pool-173-66-76-136.washdc.fios.verizon.net [173.66.76.136]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 1928F3245458; Mon, 16 May 2011 10:09:22 -0700 (PDT) Message-ID: <4DD15A40.2010209@joelhalpern.com> Date: Mon, 16 May 2011 13:09:20 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 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> In-Reply-To: <7C4DFCE962635144B8FAE8CA11D0BF1E055F693A04@MX14A.corp.emc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmcpherson@verisign.com, savi@ietf.org, gen-art@ietf.org, 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: Mon, 16 May 2011 17:09:24 -0000 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 jari.arkko@piuha.net Tue May 24 13:49:31 2011 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 38D57E0786 for ; Tue, 24 May 2011 13:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.631 X-Spam-Level: X-Spam-Status: No, score=-102.631 tagged_above=-999 required=5 tests=[AWL=-0.032, 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 w8sf2Ysxf2rP for ; Tue, 24 May 2011 13:49:30 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id A8262E0775 for ; Tue, 24 May 2011 13:49:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 127EA2CC2F; Tue, 24 May 2011 23:49:28 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbEQjeV7auEh; Tue, 24 May 2011 23:49:26 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id ADBF82CC4B; Tue, 24 May 2011 23:49:25 +0300 (EEST) Message-ID: <4DDC19D4.2040104@piuha.net> Date: Tue, 24 May 2011 22:49:24 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: draft-ietf-savi-framework@tools.ietf.org, SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [savi] AD review of draft-ietf-savi-framework 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: Tue, 24 May 2011 20:49:31 -0000 I have reviewed this draft. I think it is in relatively OK shape, though I had a number of issues. Please see below. I'm expecting a new version, and then I can start the IETF last call for this document. > Finer-grained IP > source address validation would be helpful to enable IP-source- > address-based authentication, authorization, and host localization, > as well as to efficiently identify misbehaving hosts. I would cut down this list a little bit. Source-address based authentication may not be recommended practice to begin with. Just say: Finer-grained IP source address validation would ensure that source address information is accurate, reduce the ability to launch denial-of-service attacks, and help with localizing hosts and identify misbehaving hosts. > This model allows a SAVI instance to be located anywhere on the link > to which the hosts attach, hence enabling different locations for a > SAVI instance. The term "SAVI instance" sounds a bit odd. Perhaps you could say "... allows SAVI functionality (a SAVI instance) to be located ...." > To make SAVI of better applicability, to handle the scenarios in > which hosts are not directly attached is of value. > SAVI instance is attached by a legacy switch which is attached by > hosts. The language could be improved here. > However, to take such scenario into consideration requires > support in the bind-and-identify model. > o A legacy switch to which hosts are attaching uses two trunked > ports to connect to SAVI switch. > > o STP runs among switches, and a link failure happens. > > Both scenarios require more specified design to build correct > binding. Thus, for each SAVI solution, the applicability must be > specified explicitly. > I'm not sure what this means. Please rewrite in clearer language. In particular, I had the following questions: - What specific new support is needed in the bind-and-identify model? - Is the bind-and-identify model the one that you introduced earlier? You're calling it with a different name ... based on the beginning of the Section, it should perhaps be called Identify-Bind-Enforce model. - Link failures make for complex effects to SAVI. Mere disconnection by itself is not a problem, packets just don't flow. Network partition and re-merge would cause some problems. One possible rewrite: Nevertheless, it is useful for SAVI mechanisms to be able to handle situations where hosts are not directly attached to the SAVI-capable device. For instance, deployments with both SAVI-capable and legacy switches could be supported. In general, a SAVI solution needs to specify how it deals with a number of deployment scenarios and exceptional situations, including interaction with legacy devices, hosts moving between wireless attachment points, network partitions, and so on. > o A legacy switch to which hosts are attaching uses two trunked > ports to connect to SAVI switch. > to a SAVI capable switch > The SAVI method hence comes in multiple variants: > for links with Stateless Address Autoconfiguration [rfc4862 ], for > links with DHCP [rfc2131 ][rfc3315], for links with Secure Neighbor > Discovery [rfc3971 ], for links with IKEv2 [rfc5996 ] [rfc5739 ] > [rfc5026 ] and for links that use any combination of IP address > assignment methods. > SEND is perhaps more of a variation ofg SLAAC than its own free-standing address allocation method. > The reason to develop SAVI method variants for each single IP address > configuration method, in addition to the variant that handles all IP > address assignment methods, is to minimize the complexity of the > common case: many link deployments today either are constrained to a > single IP address assignment methods or, equivalently from the > perspective of the SAVI method, separate IP address assignment > methods into different IP address prefixes. The SAVI method for such > links can be simpler than the SAVI method for links with multiple IP > address assignment methods per IP address prefix. > Hmm. I'm not sure I buy this. First of all, I would claim that many links support multiple address assignment methods. For instance, dual stack links typically today support SLAAC for IPv6 and DHCP for IPv4. And its obvious that to fly in the IETF, the SAVI solution needs to support multiple methods. I would just replace the above text with: To provide a complete solution, SAVI methods need to support a variety of address configuration mechanisms. Of course there may be different SAVI specifications that specify, for instance SAVI functionality for IPv4 and IPv6 address configuration. It is expected that SAVI methods can collectively support DHCP [rfc2131,rfc3315], Stateless Address Autoconfiguration [rfc4862 ] with or without Secure Neighbor Discovery [rfc3971], IKEv2 [rfc5996,rfc5739,rfc5026] and combinations thereof. > > 6. Mix Scenario > Mixed Scenario? > o Manually Prefix Configuration: The allowed prefix scope of IPv4 > Addresses, IPv6 static addresses, IPv6 addresses assigned by > SLAAC, and IPv6 addresses assigned by DHCPv6 can be set manually > at SAVI device. FE80::/64 is always a feasible prefix in IPv6. > I think you want: o Manual Prefix Configuration: ... > o Prefix Configuration by RA Snooping: The allowed prefix scope of > IPv6 static addresses and IPv6 addresses assigned by SLAAC can be > set at SAVI device through snooping RA message at SAVI device. > FE80::/64 is always a feasible prefix in IPv6. > > o Prefix Configuration by DHCP-PD Snooping: The allowed prefix > scope of IPv6 static addresses, IPv6 addresses assigned by SLAAC, > and IPv6 addresses assigned by DHCPv6 can be set through snooping > DHCP-PD message at SAVI device. FE80::/64 is always a feasible > prefix in IPv6. > > I don't think the FE80::/64 statement is needed on these two bullets (RAs and DHCP-PD do not use FE80 AFAIK.) > If some of the prefix scopes is set to have non prefix, it implies > corresponding address assignment method is not allowed in the > network. > ... no prefix, it implies ... > The author would like to thank the SAVI working group for a thorough The authors... > This document only discusses the possible methods to mitigrate the > usage of forged IP address, but doesn't propose a mechanism that > provides strong security for IP address. I'd say: This document only discusses the possible methods to mitigate the usage of forged IP addresses. Some such methods may rely on cryptographic methods, but not all do. As a result, it is generally not possible to prove address ownership in any strong sense. Jari From junbi@tsinghua.edu.cn Tue May 24 18:47:09 2011 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 62486E07CA for ; Tue, 24 May 2011 18:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.104 X-Spam-Level: X-Spam-Status: No, score=-101.104 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, 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 tSlSVpeihc77 for ; Tue, 24 May 2011 18:47:08 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id 45922E0764 for ; Tue, 24 May 2011 18:47:06 -0700 (PDT) Received: from th053212.ip.tsinghua.edu.cn ([59.66.53.212] helo=junbiVAIOz138) by smtp.tsinghua.edu.cn with esmtpa (Exim 4.69) (envelope-from ) id 1QP3BL-0001rw-GW; Wed, 25 May 2011 09:46:43 +0800 Message-ID: <634BEF66B2B74684B180B35F2C94BCEB@junbiVAIOz138> From: "Jun Bi" To: "Jari Arkko" , , "SAVI Mailing List" References: <4DDC19D4.2040104@piuha.net> In-Reply-To: <4DDC19D4.2040104@piuha.net> Date: Wed, 25 May 2011 09:46:43 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 Subject: Re: [savi] AD review of draft-ietf-savi-framework 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: Wed, 25 May 2011 01:47:09 -0000 Hi Jari, Thank you very much for your review, we will update a new version ASAP. Best Regards, Jun Bi -----原始邮件----- From: Jari Arkko Sent: Wednesday, May 25, 2011 4:49 AM To: draft-ietf-savi-framework@tools.ietf.org ; SAVI Mailing List Subject: [savi] AD review of draft-ietf-savi-framework I have reviewed this draft. I think it is in relatively OK shape, though I had a number of issues. Please see below. I'm expecting a new version, and then I can start the IETF last call for this document. > Finer-grained IP > source address validation would be helpful to enable IP-source- > address-based authentication, authorization, and host localization, > as well as to efficiently identify misbehaving hosts. I would cut down this list a little bit. Source-address based authentication may not be recommended practice to begin with. Just say: Finer-grained IP source address validation would ensure that source address information is accurate, reduce the ability to launch denial-of-service attacks, and help with localizing hosts and identify misbehaving hosts. > This model allows a SAVI instance to be located anywhere on the link > to which the hosts attach, hence enabling different locations for a > SAVI instance. The term "SAVI instance" sounds a bit odd. Perhaps you could say "... allows SAVI functionality (a SAVI instance) to be located ...." > To make SAVI of better applicability, to handle the scenarios in > which hosts are not directly attached is of value. > SAVI instance is attached by a legacy switch which is attached by > hosts. The language could be improved here. > However, to take such scenario into consideration requires > support in the bind-and-identify model. > o A legacy switch to which hosts are attaching uses two trunked > ports to connect to SAVI switch. > > o STP runs among switches, and a link failure happens. > > Both scenarios require more specified design to build correct > binding. Thus, for each SAVI solution, the applicability must be > specified explicitly. > I'm not sure what this means. Please rewrite in clearer language. In particular, I had the following questions: - What specific new support is needed in the bind-and-identify model? - Is the bind-and-identify model the one that you introduced earlier? You're calling it with a different name ... based on the beginning of the Section, it should perhaps be called Identify-Bind-Enforce model. - Link failures make for complex effects to SAVI. Mere disconnection by itself is not a problem, packets just don't flow. Network partition and re-merge would cause some problems. One possible rewrite: Nevertheless, it is useful for SAVI mechanisms to be able to handle situations where hosts are not directly attached to the SAVI-capable device. For instance, deployments with both SAVI-capable and legacy switches could be supported. In general, a SAVI solution needs to specify how it deals with a number of deployment scenarios and exceptional situations, including interaction with legacy devices, hosts moving between wireless attachment points, network partitions, and so on. > o A legacy switch to which hosts are attaching uses two trunked > ports to connect to SAVI switch. > to a SAVI capable switch > The SAVI method hence comes in multiple variants: > for links with Stateless Address Autoconfiguration [rfc4862 > ], for > links with DHCP [rfc2131 ][rfc3315], > for links with Secure Neighbor > Discovery [rfc3971 ], for links with > IKEv2 [rfc5996 ] [rfc5739 > ] > [rfc5026 ] and for links that use any > combination of IP address > assignment methods. > SEND is perhaps more of a variation ofg SLAAC than its own free-standing address allocation method. > The reason to develop SAVI method variants for each single IP address > configuration method, in addition to the variant that handles all IP > address assignment methods, is to minimize the complexity of the > common case: many link deployments today either are constrained to a > single IP address assignment methods or, equivalently from the > perspective of the SAVI method, separate IP address assignment > methods into different IP address prefixes. The SAVI method for such > links can be simpler than the SAVI method for links with multiple IP > address assignment methods per IP address prefix. > Hmm. I'm not sure I buy this. First of all, I would claim that many links support multiple address assignment methods. For instance, dual stack links typically today support SLAAC for IPv6 and DHCP for IPv4. And its obvious that to fly in the IETF, the SAVI solution needs to support multiple methods. I would just replace the above text with: To provide a complete solution, SAVI methods need to support a variety of address configuration mechanisms. Of course there may be different SAVI specifications that specify, for instance SAVI functionality for IPv4 and IPv6 address configuration. It is expected that SAVI methods can collectively support DHCP [rfc2131,rfc3315], Stateless Address Autoconfiguration [rfc4862 ] with or without Secure Neighbor Discovery [rfc3971], IKEv2 [rfc5996,rfc5739,rfc5026] and combinations thereof. > > 6. Mix Scenario > Mixed Scenario? > o Manually Prefix Configuration: The allowed prefix scope of IPv4 > Addresses, IPv6 static addresses, IPv6 addresses assigned by > SLAAC, and IPv6 addresses assigned by DHCPv6 can be set manually > at SAVI device. FE80::/64 is always a feasible prefix in IPv6. > I think you want: o Manual Prefix Configuration: ... > o Prefix Configuration by RA Snooping: The allowed prefix scope of > IPv6 static addresses and IPv6 addresses assigned by SLAAC can be > set at SAVI device through snooping RA message at SAVI device. > FE80::/64 is always a feasible prefix in IPv6. > > o Prefix Configuration by DHCP-PD Snooping: The allowed prefix > scope of IPv6 static addresses, IPv6 addresses assigned by SLAAC, > and IPv6 addresses assigned by DHCPv6 can be set through snooping > DHCP-PD message at SAVI device. FE80::/64 is always a feasible > prefix in IPv6. > > I don't think the FE80::/64 statement is needed on these two bullets (RAs and DHCP-PD do not use FE80 AFAIK.) > If some of the prefix scopes is set to have non prefix, it implies > corresponding address assignment method is not allowed in the > network. > ... no prefix, it implies ... > The author would like to thank the SAVI working group for a thorough The authors... > This document only discusses the possible methods to mitigrate the > usage of forged IP address, but doesn't propose a mechanism that > provides strong security for IP address. I'd say: This document only discusses the possible methods to mitigate the usage of forged IP addresses. Some such methods may rely on cryptographic methods, but not all do. As a result, it is generally not possible to prove address ownership in any strong sense. Jari _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Fri May 27 00:20:40 2011 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 30F90E078E for ; Fri, 27 May 2011 00:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 PKRWffZw89JX for ; Fri, 27 May 2011 00:20:39 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 83128E0785 for ; Fri, 27 May 2011 00:20:37 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (216.219-78-194.adsl-static.isp.belgacom.be [194.78.219.216]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 75BEC6FA8CF for ; Fri, 27 May 2011 09:20:31 +0200 (CEST) Message-ID: <4DDF50BD.7080301@it.uc3m.es> Date: Fri, 27 May 2011 09:20:29 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: savi@ietf.org References: <4DDC19D4.2040104@piuha.net> <634BEF66B2B74684B180B35F2C94BCEB@junbiVAIOz138> In-Reply-To: <634BEF66B2B74684B180B35F2C94BCEB@junbiVAIOz138> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18162.003 Subject: Re: [savi] AD review of draft-ietf-savi-framework 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: Fri, 27 May 2011 07:20:40 -0000 one reply El 25/05/11 3:46, Jun Bi escribió: > >> configuration method, in addition to the variant that handles all IP >> address assignment methods, is to minimize the complexity of the >> common case: many link deployments today either are constrained to a >> single IP address assignment methods or, equivalently from the >> perspective of the SAVI method, separate IP address assignment >> methods into different IP address prefixes. The SAVI method for such >> links can be simpler than the SAVI method for links with multiple IP >> address assignment methods per IP address prefix. >> > The reason to develop SAVI method variants for each single IP address > > Hmm. I'm not sure I buy this. First of all, I would claim that many > links support multiple address assignment methods. For instance, dual > stack links typically today support SLAAC for IPv6 and DHCP for IPv4. > And its obvious that to fly in the IETF, the SAVI solution needs to > support multiple methods. I would just replace the above text with: > The difficult case here is when different methods are used to assign addresses _from the same prefix_ This case is complicated because different methods can assign the same address and SAVI needs to be able to determine which is the winning method. So, while i agree with you that it is fairly common the case where multiple address assignment methods are used in a given link, i believe that the case where multiple address assignement methods assign addresses from the same prefix is much less common. I guess we need to make the distinction clearer in the document. Regards, marcelo From junbi@cernet.edu.cn Fri May 27 04:56:23 2011 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 57DDAE0679 for ; Fri, 27 May 2011 04:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.489 X-Spam-Level: X-Spam-Status: No, score=-97.489 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_HAS_XAIMC=2.696, 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 BorIgYpMA-eG for ; Fri, 27 May 2011 04:56:22 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 88715E0688 for ; Fri, 27 May 2011 04:56:20 -0700 (PDT) Received: from junbiVAIOz138([59.66.24.191]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm114ddfc44c; Fri, 27 May 2011 19:56:18 +0800 Message-ID: <44FC25D1DD22493EAC47AAA563439C61@junbiVAIOz138> From: "Jun Bi" To: "marcelo bagnulo braun" , References: <4DDC19D4.2040104@piuha.net><634BEF66B2B74684B180B35F2C94BCEB@junbiVAIOz138> <4DDF50BD.7080301@it.uc3m.es> In-Reply-To: <4DDF50BD.7080301@it.uc3m.es> Date: Fri, 27 May 2011 19:56:16 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3508.1109 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3508.1109 X-AIMC-AUTH: junbi X-AIMC-MAILFROM: junbi@cernet.edu.cn X-AIMC-Msg-ID: OyWevZ0B Subject: Re: [savi] AD review of draft-ietf-savi-framework 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: Fri, 27 May 2011 11:56:23 -0000 Yes, marcelo is right. I rememer in the round of WG chair review, it was discussed, so I think the text below in the curren verison already reflects the Marcelo's meaning. "is to minimize the complexity of the common case: many link deployments today either ...... or, equivalently from the perspective of the SAVI method, separate IP address assignment methods into different IP address prefixes. " thanks， Jun -----原始邮件----- From: marcelo bagnulo braun Sent: Friday, May 27, 2011 3:20 PM To: savi@ietf.org Subject: Re: [savi] AD review of draft-ietf-savi-framework one reply El 25/05/11 3:46, Jun Bi escribió: > >> configuration method, in addition to the variant that handles all IP >> address assignment methods, is to minimize the complexity of the >> common case: many link deployments today either are constrained to a >> single IP address assignment methods or, equivalently from the >> perspective of the SAVI method, separate IP address assignment >> methods into different IP address prefixes. The SAVI method for such >> links can be simpler than the SAVI method for links with multiple IP >> address assignment methods per IP address prefix. >> > The reason to develop SAVI method variants for each single IP address > > Hmm. I'm not sure I buy this. First of all, I would claim that many > links support multiple address assignment methods. For instance, dual > stack links typically today support SLAAC for IPv6 and DHCP for IPv4. > And its obvious that to fly in the IETF, the SAVI solution needs to > support multiple methods. I would just replace the above text with: > The difficult case here is when different methods are used to assign addresses _from the same prefix_ This case is complicated because different methods can assign the same address and SAVI needs to be able to determine which is the winning method. So, while i agree with you that it is fairly common the case where multiple address assignment methods are used in a given link, i believe that the case where multiple address assignement methods assign addresses from the same prefix is much less common. I guess we need to make the distinction clearer in the document. Regards, marcelo _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From jari.arkko@piuha.net Mon May 30 00:03:43 2011 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 26BD8E077E; Mon, 30 May 2011 00:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 wPssnYIXJWFM; Mon, 30 May 2011 00:03:41 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3BEE0773; Mon, 30 May 2011 00:03:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EC2EA2CC49; Mon, 30 May 2011 10:03:37 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOLB1X7caax2; Mon, 30 May 2011 10:03:36 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 149062CC2F; Mon, 30 May 2011 10:03:36 +0300 (EEST) Message-ID: <4DE34147.8070103@piuha.net> Date: Mon, 30 May 2011 10:03:35 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: SAVI Mailing List , draft-ietf-savi-threat-scope@tools.ietf.org References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> In-Reply-To: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IESG Subject: [savi] Status of draft-ietf-savi-threat-scope 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, 30 May 2011 07:03:43 -0000 This draft was in IESG review last week. Please see below for the comments that were raised. I would like the authors to correct these issues and/or respond to the Discuss holders, as appropriate. There are many detailed things, but the key takeaways that I took from my IESG colleagues were the following: * Changes agreed after Gen-ART discussion need to be incorporated in a new version of the document (Russ' Discuss) * Many of the issues around precise definitions and additional information brought up by Ralph's Discuss seemed correct. Please ensure that you adopt these in a new version as well. * I think you need to fix many of the details pointed to in Stephen's Discuss, and explain that this document is not the one that will describe what the residual threats are after SAVI is implemented. (That would be the job of the individual SAVI mechanism documents). Jari > > Dan Romascanu > > *Comment (2011-05-25)* > > I find the document comprehensive but I share DBH's observation that it's a > little too verbose and could use some fixes in the details. > > Beyond what he found I have a few more observations. None is critical for this > informational document, but cleaning up all these text unclarities in a new > version would be recommended; > > 1. In the Glossary section > > NNI Router: Network to Network Interface Router. This router > interface faces a similar system operated by another ISP or other > large network. > > I think that the definition should read something like 'A router with interfaces > facing a similar system ...' > > 2. Section 4.2.3.3 > > IEEE 802.1x is an authentication protocol that permits a network to > determine the identity of a system seeking to join it and apply > authorization rules to permit or deny the action. In and of > themselves, such tools confirm only that the user is authorized to > use the network, but do not enforce what IP address the user is > allowed to use. It is worth noting that elements of 802.1x may well > be useful as binding anchors for SAVI solutions. > > This is quite confusing. IEEE 802.1X is a port (in the sense of bridge or layer > 2 switch) access control standard that controls the joining of devices to a > layer 2 bridged network. The term 'tools' is not in place and there is nothing > about the 'user' in the protocol itself but about the device - the standard uses > the term 'supplicant' which is rather the device or the piece of software > running on the device that presents credentials to an authenticator. > > 3. In section 5.2 'hosts connected to switch ports that may have one or more IP > addresses' is probably rather 'hosts that may have one or more IP addresses > connected to (layer 2) switch ports' > > > David Harrington > > *Comment (2011-05-23)* > > I found this document to be very informative about the problem space. > I think > this document could have been far more effective if the text didn't meander > around the points it was trying to make; it could habve been far more succinct. > Here are some suggestions that I think could improve the document. > > 1) I find the following ambiguous, "the operational staff needs to be able to > track from the IP address sourcing the attack to the particular machine within > the enterprise that is the source. " I think the intention is that "the IP > address sourcing the attack" means the spoofed address, and "that is the source" > means the actual sending machine, but I'm not sure. This can be read as "the > staff needs to track from the source to the source." > 2) This sentence doesn't > parse properly, "This both that the information be useable ..." I think the > sentence is missing "means" or "requires" or something. > 3) The glossary should > include references to the defining documents. > 4) "or order to disrupt" -> "in > order to disrupt" > 5) 3.1.3 doesn't describe what a poison attack is. It also > refers to "the same kinds of poisonings as above", but above never spoke of > poisoning attacks. > 6) the following seems a bit perverted logic - a malware > attack is important because it is a justification for SAVI? > "This attack is > important both in terms of an attack vector that SAVI may help prevent, and also > as a problem which SAVI can help track back to find infected systems. " > Shouldn't you be arguing that savi is important for preventing these types of > attacks? > 7) section 3.2.2 "Another example of sighted attack" - this is the > first mention of "sighted attack". Please use consistent terminology. > 8) in > section 3.2.2, "The use of spoofed addresses, while not necessary for this, can > often provide additional information, and helps mask the traceability of the > activity." would seem to be the conclusion of the paragraph, but this precedes > the discussion of what the attack is. > 9) in scetion 4, "the first requirement" > isn't followed by any further requirements. and is this section going to > describe the requirements or the solutions? > 10) "The IP source address is > appropriate for the lower layer address (they both identify the same system)". > I find "is appropriate" too ambiguous, although the following parethetical text > explains it. I suggest this would be better written as "the IP source address > and the lower layer address both identify the same system." > 11) "The IP source > address is appropriate for the device at the layer 2 switch port" I find "is > appropriate" too ambiguous. > " (the address was assigned to a, and perhaps the, > system that uses that port) " doesn't parse appropriately. I think this bullet > needs a better description. > 12) section 4.1.1 "Port identification prevents > transmission of malicious datagrams" Is thistrue? or is port identification one > method that can be used to help prevent transmission? > 13) 4.1.3 "An obvious > special case of the discussion is with an ISP PE router, " - what discussion? > This section seems based on speculation about possible solutions, including > contract negotiations. I think this would be much better if it actually focused > on technical solutions for validating addresses for ISP edge routers. > 14) 4.1.4 > again discusses business agreements between two conpanies. Please focus on > ***technical*** solutions at this topological location. > 15) 4.1.4 "However, when > it can be shown that spoofed addresses are present, the procedure can be > applied. " what procedure? > 16) 4.2.5 is entitled residual attacks, but there is > no discussion of residual attacks in the paragraph. The hand-waving contained in > the paragraph doesn't seem worth documenting. > 17) why is 4.2.5, "residual > attacks", included in section 4 "Current anti-spoofing solutions"? > 18) 5.2.6 > what does "proper member" mean? where is this defined? > 19) 5.2.7 - doesn't this > sum up the whole section 5? since it includes anything not covered in 5.1 or > 5.2, shouldn't this be 5.3? > 20) is 5.3 about topological challenges? it seems to > meander on about additioonal capabilites, rather than discussing the topological > challenge to SAVI. > > > Peter Saint-Andre > > *Comment (2011-05-23)* > > Please expand "DoS" on first use and add an informational reference to RFC 4732. > > > Russ Housley > > *Discuss (2011-05-24)* > > The Gen-ART Review by David Black on 12-May-2011 lead to a discussion > with one of the authors. At the end of the discussion, several > changes to the document were agreed. However, those changes have > not been made. > > > Stewart Bryant > > *Comment (2011-05-23)* > > A useful document which I enjoyed reading > > > > Wesley Eddy > > *Comment (2011-05-24)* > > The document looks good, I just have a few comments that the authors might think > about: > > Section 3.1.7 is titled "other blind spoofing attacks" but talks about non-blind > attacks just as much. The example given of a host on-link with routers is non- > blind, for instance. However, seciton 3.2 is where non-blind attacks are > supposed to be discussed, so this part of 3.1.7 seems rather odd. > > > Why isn't the relationship to SeND discussed in this document? > > > VPN gateways have similar considerations as the Mobile IP HA in sectino 5.2.6, > but VPN gateways don't appear to be discussed in 5.2. > > > Ralph Droms > > *Discuss (2011-05-25)* > > I will raise a meta-discussion issue before listing several specific > Discuss points. This issue may be just the suppressed pedantic > ex-professor side of my personality expressing itself. My issue is > that the contents of this document are useful and not incorrect. > However, in my opinion the document would be more useful, especially > to someone who reads this document without a lot of background in the > type of threats described, with some additional detail. I could be > persuaded that I am being overly pedantic, in which case I will clear > my Discuss and move my points to Comments. I will be happy to send > text if the authors would find it helpful. > > 1. In section 1: > > At the IP Network Layer, or Internet Layer, there is typically no > required transactional state when communicating with other hosts on > the network. Hosts generating packets for transmission have the > opportunity to spoof (forge) the source address of packets which they > transmit. > > I think this paragraph needs more detail to connect the first sentence > with the last sentence. > > 2. Next paragraph: > > Source address verification is necessary in order to detect and > reject spoofed packets and contribute to the overall security of IP > networks. In particular, source address verification techniques > enable detection and rejection of spoofed packets, and also > implicitly provide some assurances that the source address in an IP > packet is legitimately assigned to the system that generated the > packet. > > "Source address verification" can be used or is necessary? You > haven't told us what source address verification is, yet. The second > sentence in this paragraph doesn't seem to add any new information. > What would be more helpful would be a sentence or two foreshadowing > the details in section 3. Why are packets with spoofed addresses > dangerous? > > 3. The attacks in section 3 fall, roughly, into two buckets: those that > require spoofed source addresses and those that can use spoofed > addresses to obfuscate the source of the attack. SAVI can eliminate > the former but only deter, through threat of discovering the > perpetrator, the latter. The difference is important to someone using > this document to learn about how SAVI contributes to security in a > network. Otherwise, a network administrator might expect to eliminate > all of the listed attacks with SAVI. > > An improvement would be to explain the two types of attacks and > indicate the type of the attacks in section 3. > > 4. I found the second sentence of the first paragraph of section 4 > very hard to parse and not entirely consistent with the title of the > section. While most of the solutions in section 4 have to do with the > network topology, the first bullet: > > o The IP source address is appropriate for the lower layer address > (they both identify the same system) > > has nothing to do with network topology. > > The second bullet: > > o The IP source address is appropriate for the device at the layer 2 > switch port (the address was assigned to a, and perhaps the, > system that uses that port) > > does use network topology, but seems specific to wired networks; in > fact, later in section 4, wireless networks are mentioned as using > different techniques. Might be better to write: > > o The IP source address is explicitly identified as appropriate > for the physical topology; for example, the source address > is appropriate for the layer 2 switch port through which the > datagram was received > > 5. Section 4.1.1 changes in mid-section from checking the IP address > against the Link Layer address to checking the IP address against the > physical attachment point. Is Link Layer address checking ever > implemented on switches or is it always IP address checking versus the > physical attachment point? > > 6. I suggest augmenting section 4.1.3 with a mention of IPv6 prefix > checking, where the PE can be populated with the customer prefix > through monitoring DHCPv6 prefix delegation. > > Also, the enterprise case can be augmented with prefix filtering based > on the prefixes known by the ISP to be assigned to the customer. > > 7. Sections 4.1.5 either needs more detail or pointers to references > where more detail is available. In its current form, it has little > or no content. The interesting parts of DOCSIS are the authentication > and trust model, in which the ISP can control and trust the cable > modem. > > 8. Section 4.1.6 has more detail than section 4.1.5, but assumes some > experience with DSL deployments and architectures. Both of these > sections would benefit from some explanation of the accountability > model in which packets can be traced to an accountable entity, > regardless of the specific address or prefix in the source address of > a packet. > > 9. Section 4.2.3.2 might benefit from just a little more detail, or a > pointer to more detail: > > switch uses IP address to port binding > switch enforces restrictions that DHCP server traffic is only > accepted from "upstream" > switch monitors DHCP traffic to glean address-port bindings > > This technique works for both IPv4 and IPv6. > > And, the discussion of SLAAC brings up the issue of authenticated SAVI > versus "ad hoc" SAVI. In the case of DHCP based SAVI, the switch can > have authoritative information about the address/port binding, because > it came from a reliable source (DHCP server). SLAAC-based SAVI can > only identify claimed addresses, where the hose may not be authorized > to use the claimed address. > > 10. Are the techniques mentioned in 4.2.4 really SAVI? > > 11. What is a "residual attack" and how does the text in section 4.2.5 > describe a residual attack? > > > *Comment (2011-05-25)* > > 1. Add DoS (yeah, I know DoS is pretty widely used already), "binding > anchor" (and use "binding anchor" through the document), MITM, LAND, > smurf attack, uRPF to section 2. Some of these also have first-use > expansion, which might be OK ... this suggestion is just a Comment. > > 2. Suggestion: it would be more useful to incorporate any issues > specific to IPv6 in the body of the document. > > 3. First sentence of section 4: > > The first requirement is to eliminate datagrams with spoofed IP > addresses from the Internet. > > First requirement for what? I thought this document was exactly about > "eliminat[ing] datagrams with spoofed IP addresses from the Internet." > I suggest dropping the sentence. > > 4. At the end of section 4, the bullet list calls out "enterprise CPE > Router" explicitly. Aren't residential CPE routers also a big > opportunity? How are they different from enterprise CPE routers. In > fact, perhaps "CPE" is not the best term? How about "Enterprise edge > router" and add "subscriber home router"? > > 5. At the end of section 1, have the strength of your convictions: > > This document provides [...], and discusses [...]. > > 6. For consistency, in sections 3.2.1 and 4.1.1 > s/MAC address/Layer 2 address/ > > 7. Is "source address verification" equivalent to "Source Address > Validation Improvement (SAVI)"? If so, for consistency use one phrase > or acronym throughout. > > > Stephen Farrell > > *Discuss (2011-05-26)* > > (1) What's the difference between "validation" (abstract) and > "verification" (overview, 3rd para) as used here? If there is > none, then just use one. If this is a difference, then where are > these defined? I think in either case, some definition is needed. > > (2) I expected this document to also analyse source-address > spoofing threats after SAVI mechanisms are deployed. If some simple > form(s) of source address spoofing will work regardless of which > SAVI mechanism(s) are in place then one would have to wonder if > SAVI is worth deploying or not. If this is not the right document > to cover that then what is? The fact that the SAVI mechanisms will > each be in separate documents would seem to mean that this question > won't otherwise be answered by the WG, and I think we do need an > answer somewhere. (The security considerations of the SAVI > framework is currently one paragraph so that's not the place, at > least not now.) Its probably worth noting that this issue is behind > a number of cases below where I ask for evidence to justify what > appear to be overly broad claims made. > > (3) What is the evidence that "Source address verification is > necessary in order to detect and reject spoofed packets"? I'm > asking why this is "necessary"as opposed to sufficient (if it is > sufficient - see (2) above). > > (2) This presumably needs some form of qualification if not all > packets with spoofed source addresses can be spotted: "source > address verification techniques enable detection and rejection of > spoofed packets." I'm not sure if "some spoofed packets" would be a > good thing to say there but it does seem to be the case - a better > qualification (or a forward reference to where that is described) > would represent truth-in-advertising. > > (3) Where in the charter is "local traceability" in scope? The > charter does say that "tracking other protocols is not in scope" so > local traceability needs to be defined as something limited > to/scoped to spoofed source addresses. > > (4) "For example, when an enterprise receives a report of an attack > originating within that enterprise, the operational staff needs to > be able to track from the IP address sourcing the attack to the > particular machine within the enterprise that is the source." I > don't think that's true in general - "needs" is wrong since there > can be other ways to find a zombie. > > (5) Spoofing is defined to cover both IP and MAC address spoofing. > SAVI does not address the latter I believe (right?). If so, then I > think you need to separate these as otherwise confusion between > them might lead to incorrect conclusions being stated. Spoofing is > also defined as "forging" but that is not defined and could be > considered to be synonymous with "spoofing" here which would make > this a circular definition. I think the definition of spoofing > needs to be more precise basically. > > (6) 3.1: " The result is that they have no access to legitimate > source and target systems." I think that's wrong - are you trying > to say that "The attacker in this case should have no legitimate > access to source and target systems." > > (7) Does the ARP example in 3.2.1 really involve a spoofed IP > source? If not, then you should note that its not in scope for > SAVI. If it is, then say why its in scope. > > (8) I'd be interested in knowing if SAVI can help with 3.2.2 - if > not then saying so would be right. If so, then saying when SAVI > might help would be good. > > (9) If "The first requirement is to eliminate datagrams with > spoofed IP addresses from the Internet." then SAVI would seem to be > facing an impossible problem. The "can eliminate such datagrams" > part also seems overstated - where's the evidence that that's true? > s/eliminate/reduce/ would seem to be more correct. > > (10) Saying that "Internet devices can...confirm...that the IP > address is appropriate for the lower layer address" is not true of > all "Internet devices" only for some near the source, so that's > also overstated and needs to be qualified. (It is later to be fair > but the statement itself is wrong.) > > (11) I don't know the answer here, so this is just a question - > what is the likelihood the uRPF check works well? (I didn't find > the string uRPF in RFC 3704, so I'm not sure, but I didn't really > read 3704;-) I guess the real question is whether a failure in uRPF > might break anything for a non-spoofing host and whether a spoofing > host could make it so that uRPF checks allow the packet with a > spoofed address through (from e.g. the same subnet, or for certain > guessable source addresses). I ask (in part) since 4.2.2 says that > uRPF is a crude mechanism. > > (12) I'm not sure whether 4.1.3 and 4.1.4 are in or out of scope > for SAVI. Can you make that clear? > > (13) What does "unforgeable" mean in 4.2.3? Perhaps you need to > define that term as well? It may be that the meaning differs for > e.g. MAC addresses and other credentials (noting that passwords can > be guessed or shared of course). > > (14) In 4.2.3 where is the evidence that "a large portion of the > ...threat space...can be marginalized" - I think that needs some > qualification. > > (15) 4.2.3.2 says that DHCP and sniffing "can...auotmatically > provide sufficient binding information" - is there evidence for > that somewhere? Be good to reference it. > > (16) 802.1X determines the identity of a user, not a system I > think. > > (17) I think 4.2.5 needs to better characterise the "residual > threat" (not "residual attack") - for each of the various forms of > SAVI. I had hoped this document would say what spoofing > possibilities remain. Providing just one example doesn't seem > sufficient. > > (18) Section 6 (at least) should also recognise that there are > privacy considerations that apply and that more-or-less directly > run counter to the ability to trace the source of problems. > > (19) Section 8 should note that circumstantial evidence linking a > person to an IP address can be dangerous for the person. There have > been cases where such tracking has mis-identified people > responsible for some act. (I don't have a reference to hand sorry.) > > (20) If no set of deployed SAVI instances can prevent all spoofing > from a given network then an attacker could probe the network to > find out what spoofing works from where they are at, and then use > that. Success in spoofing would then likely have more consequences > for an innocent spoofed party. This would be a new threat caused by > SAVI itself. > > (21) If binding anchors are personally identifying or stable over > time or location then recording those creates new threats for tracking > the user or host associated with the binding anchor. That needs to > be noted. > > > *Comment (2011-05-26)* > > (1) 2nd para of overview says that there is "typically no required > transactional state when communicating with other hosts on the > network." I think it'd be good to say why that's the case, via a > reference to something. (Not sure what reference is best exactly.) > > (2) What is a "better Internet participant"? It sounds like a scary > thing. > > (3) s/This both that the information be useable/This requires both > that the information be useable/ > > (4) I expected to see some CVE references in section 3 but didn't > see any. I'd encourage adding some of those for each of the threats > covered since that should help motivate the work and would > demonstrate that there are real threats to mitigate. (E.g. a quick > search on "CVE spoofed source" throws up a bunch.) To take one > example, 3.1.4 could do with such a reference. > > (5) Expand "LAND" > > (6) The DNS attack described around the top of page 9 isn't > relevant to SAVI, right? Maybe the smurf attack is enough there. > > (7) Do 3.1.6 and 3.1.7 really fit in 3.1? > > (8) Do *all* CMTS employ DOCSIS? 4.1.5 says that they do. > > (9) Even IPsec doesn't unquestionably verify source address if > load-balancing is in place with private key sharing. From jari.arkko@piuha.net Mon May 30 00:15:53 2011 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 E93BFE0692; Mon, 30 May 2011 00:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, 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 3WLSM9ftUCXH; Mon, 30 May 2011 00:15:51 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 6F031E06EC; Mon, 30 May 2011 00:15:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 7887E2CC49; Mon, 30 May 2011 10:15:46 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zGWNTQcGmft; Mon, 30 May 2011 10:15:44 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 637A62CC2F; Mon, 30 May 2011 10:15:43 +0300 (EEST) Message-ID: <4DE3441E.6000801@piuha.net> Date: Mon, 30 May 2011 10:15:42 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: SAVI Mailing List , draft-ietf-savi-fcfs@tools.ietf.org, IESG References: <20110526184022.21773.97885.idtracker@ietfa.amsl.com> In-Reply-To: <20110526184022.21773.97885.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [savi] Status of draft-ietf-savi-fcfs 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, 30 May 2011 07:15:54 -0000 This draft was in IESG review last week. There are quite many Discusses, but I think they are relatively easily dealt with. Please respond to the Discuss holders and take care of everything that was reported. There were many details and I have not had time to analyze every single issue, but the key points that I got from my IESG colleagues are as follows: * You should fix the reference issue that Dan brought up. * You should narrow down the specification to cover the switched ports case, as that is the only that you have really specified in full. Future specifications may explain how to use this technology in some other context. (Russ' and David's Discusses) * You should make the changes suggested by Stephen to avoid privacy impacts of unnecessary logging information from this technology * You should address the specific issues brought up by Wes and Ralph * I will ask Sean to remove his Discuss, as the primary issues have been removed and his just agreeing with Jari > Summary: /Has 7 DISCUSSes. Has enough positions to pass once DISCUSSes > are resolved./ > > > Adrian Farrel > > *Comment (2011-05-25)* > > There are plenty of Discuss points already raised with which I agree. > > --- > > Section 1 > "The proposed mechanism..." > It is no longer a proposal. > > --- > > The figure on page 9 has a misalignment. > > --- > > The writeup says: > There are existing implementations of a very similar feature for > IPv4. > This is fair enough, but I am surprised to see no reference to this in > the document and no description of the differences. > > > Dan Romascanu > > *Discuss (2011-05-26)* > > Section 3.2.5 speaks 'the case the SAVI device is a switch that supports > VLANs'but provides no reference to what IEEE 802,1 specification it refers and > what types of VLAN capable bridges (switches) are covered. Is the intent to > cover all types of VLANs defined by IEEE 802.1? Clarification and proper > references are required. > > > Pete Resnick > > *Comment (2011-05-24)* > > Section 2 title - I would prefer to strike "non-normative". I see > no reason for it and the use of this expression is turning into an > IETF fetish. Instead, you can add on to the the Introduction: > "Section 2 gives the background and description of FCFS SAVI, > and Section 3 specifies the FCFS SAVI protocol." > > Section 2.6: > > Before creating a SAVI > binding in the local SAVI database, the SAVI device will send a NSOL > message querying for the address involved. Should any host reply to > that message with a NADV message, the SAVI device that sent the NSOL > will infer that a binding for that address exists in another SAVI > device and will not create a local binding for it. If no NADV > message is received as a reply to the NSOL, then the local SAVI > device will infer that no binding for that address exists in other > SAVI device and will create the local SAVI binding for that address. > (NOTE that the description included here is overly simplified to > illustrate the mechanism used to preserve the coherency of the > binding databases of the different SAVI devices. The actual SAVI > mechanism normative specification as described in Section 3 varies in > the fact that in some cases it is the SAVI device that generates the > NSOL while in other cases it simply forwards the NSOL generated by > the end host, and that the SAVI device will send multiple copies of > the NSOL in order to improve the reliability of the message exchange, > among other things). > > Start with the words, "As a simplified example of how this might work:", > and then strike the parenthetical NOTE entirely. > > Section 3 title - strike "normative" > > > Peter Saint-Andre > > *Comment (2011-05-23)* > > Please expand "DoS" on first use and add an informational reference to RFC 4732. > > > Sean Turner > > *Discuss (2011-05-26)* > > Edited to remove #2. > > #1) Many of the discusses that have been logged I agree with. > > #2) addressed: I've been convinced that standards track is okay. > > > Stewart Bryant > > *Comment (2011-05-25)* > > I support the discusses raised against this document. > > > David Harrington > > *Discuss (2011-05-27)* > > There are many points in my DISCUSS, but most are requests to tighten the > RFC2119 language, or explain in the text what the valid exceptions are to each > SHOULD. > > 2) in 2.4, "For the rest of the document, we will assume that the binding > anchors are ports of a switched network." Having this statement at the end of a > paragraph in non-normative background text seems insufficient. To be compliant > to this standard, the binding anchors MUST be ports of a switched network. I > think this should be clearly specified in RFC2119 langauge in the normative > section. > > 3) in 2.5, "a secondary goal is to assist in traceability for determining who an > improper actor is." I don't see this in the charter, and question whether this > is an IETF-supported secondary goal. (I see that Stephen has raised a DISCUSS on > this in more detail). > > 4) in 3.2.2, "transit traffic and the packet SHOULD be discarded" why only > SHOULD? what are the valid exceptions to this? > 5) in 3.2.3, "the SAVI device > SHOULD execute the process of sending Neighbour Solicitation messages" > s/SHOULD/MUST/ > 6) "are NOT forwarded" s/are NOT/MUST NOT be/ > s/they are > sent/they MUST be sent/ > s/are discarded/MUST be discarded/ > s/is discarded/MUST > be discarded/ > s/packet is either stored or discarded/ - why the choice? Please > use RFC2119 language. > ... the rest o fthe state table shoul dbe in RFC2119 > terms. > s/relay/rely/ > s/must join/MUST join/ > s/SHOULD join/MUST join/ > 7) 3.2.4 > "SHOULD be connected" - when is ti valid to not be connected? should thi sbe a > MUST to ensure that transit traffic is not dropped? > multiple SHOULDs here; why > not MUSTs? If SHOULD, what are the valid exceptions? > 8) 3.2.5 "will behave as if > " - MUST behave as if > 9) section 4, why 4 bindings? where did 4 come from? > Doesn't this exhuast memory four times faster than an implementation that > reserves memory for 1 binding per port? Isn't the reserved memory wasted if the > port consistently has only one binding? > 10) "A SAVI device MUST limit the amount > of memory" I think this should be a SHOULD. If an implemnter chooses to allocate > unlimited memory, they should probably be allowed to. How will thi sbeing a > SHOULD impact interoperability, as compared to its being a MUST? > 11) "The other > type of attack is when an attacker manages to create state in the SAVI device > that will result in blocking the data packets sent by the legitimate owner of > the address. In IPv6 these attacks are not an issue thanks to the 2^64 addresses > available in each link." I don't see how the 2^64 addresses available mitigates > the ability of an attacker to create state that would block a valid address. > 12) > "the SAVI device can be used as an amplifier by attackers. In order to limit > this type of attack, it is RECOMMENDED that the SAVI device performs rate > limiting " why not MUST? > > *Comment (2011-05-24)* > > 1) in 2.3, "SAVI checks would not be fulfilled by the transit traffic" I think > fulfilled might be the wrong word here; do you mean performed? > > 2) a stylistiuc point. The document often uses "This means". This is totally > unnecessary. Just say what it means without the "this means phrase". This means > don't use this means. > > 3) in 2.6, summary, "A SAVI device only verifies packets coming through one > interface connected to the untrusted part of the topology." why only ***one > interface*** per SAVI device? > > 4) in 2.6, "In particular, it is important to avoid that the same source address > is bound to different binding anchors in different SAVI devices. Should that > occur, then it would mean that two hosts are allowed to send packets with the > same source address, which is what SAVI is trying to prevent." Is this accurate? > Does it necessarily imply there are two hosts? > > > Ralph Droms > > *Discuss (2011-05-24)* > > 1. The definitions of "source address validation", "address ownership" > and the concept that a " source address [...] belongs to the > originator of the packet" need to be clarified this paragraph: > > 2.3. Address ownership proof > > The main function performed by FCFS SAVI is to verify that the source > address used in data packets actually belongs to the originator of > the packet. Since FCFS SAVI scope is limited to the local link, the > originator of the packet is attached to the local link. In order to > define a source address validation solution, we need to define some > address ownership proof concept i.e. what it means that a given host > owns a given address in the sense that the host is entitled to send > packets with that source address. > > FCFS SAVI does not require that a host provide any sort of proof of > "ownership" of an address before that address is registered in an FCFS > SAVI function. A host merely needs to claim the address through > traffic sent to the FCFS SAVI function. In contrast, a SAVI function > implemented by bindings learned through manual configuration or > through interactions with a DHCPv6 address assignment function can > make a statement that an IP address belongs to a host. > > What FCFS SAVI does is prevent simultaneous use of a single IP address > as a source address through multiple ports. There is no guarantee > that the FCFS binding in any way reflects intended ownership of the > bound address. > > 2. There needs to be text in section 2.1 explaining why FCFS SAVI is > applicable or inapplicable to addresses assigned through DHCPv6. > > 3. What about links for which there are no prefixes that are > advertised as on-link? Similarly, what about addresses that are > assigned through DHCPv6 but are not taken from an on-link prefix? > > 4. In section 3.2.2: > > * If the IP source address does not belong to one of the local > prefixes of the receiving interface, this means that the data > packet is transit traffic and the packet SHOULD be discarded. > > s/SHOULD/MUST/ > > How are the FCFS SAVI assumptions maintained and how is > spoofed traffic discarded if the FCFS SAVI function decides to forward > transit traffic? > > 5. Section 3.2.4 must be worded more strongly to guarantee FCFS SAVI > protection. Some of the items in the list are "MUST" or FCFS SAVI > protection will not be provided: > > o Ports connected to hosts SHOULD be configured as Validating ports. > Not doing so will allow the host connected to that port to send > packets with spoofed source address. > o Ports connected to a chain of one or more legacy switches that > have hosts connected SHOULD be configured as Validating ports. > Not doing so will allow the host connected to any of these > switches to send packets with spoofed source address. > > This requirement is a MUST. There are no alternatives to the given > configurations that still provide FCFS SAVI protection. > > 6. I agree with Stephen Farrell's DISCUSS points 3 and 4, but feel > less strongly about a fix. Specifically, I agree that FCFS SAVI is > inappropriate for a deployment in which an external router can pass > transit traffic to an FCFS SAVI function. But that just means SAVI > FCFS is inappropriate. There are other SAVI mechanisms that can work; > for example, a DHCPv6-based mechanism in which the (non-FCFS) SAVI > function is aware of the addresses and prefixes assigned through a > binding anchor and, therefore, bound to that binding anchor. > > One way to address this issue some additional text describing how SAVI > can be used to provide perimeter security, where that SAVI might be > FCFS SAVI over part of the perimeter or some other kind of SAVI over > the remainder of the perimeter. > > 7. This paragraph from section 4 needs some clarification: > > The other type of attack is when an attacker manages to create state > in the SAVI device that will result in blocking the data packets sent > by the legitimate owner of the address. In IPv6 these attacks are > not an issue thanks to the 2^64 addresses available in each link. > > Random address selection makes it difficult for an attacker to hijack > an address and deny legitimate use of an address. However, in > deployments that use SLAAC, a host has a predictable global address > (perhaps augmented by random privacy addresses) that can be hijacked. > > 8. In TESTING_VP state, section 3.2.3: > > o If a data packet is received through a Trusted Port port that is > other than port P, the state is moved to TESTING_TP-LT, and the > packet MAY is discarded. > > Certainly it can't be just any packet received through a Trusted Port > that triggers this action. And, if P is a validating port, won't > traffic on any Trusted Port be "other than port P"? This bullet needs > to be corrected. > > 9. Throughout section 3.2.3, there are several occurrences of "If a > DAD_NSOL" which need the qualification ""with target address set to > IPAddr". > > 10. In section 3.2.3, does "==" mean "is set to"? In the last bullet > of TESTING_VP, does the FCFS SAVI function continue the TESTING_VP > state and is the lifetime modified? > > > *Comment (2011-05-24)* > > 1. What is the relationship between the contributors in section 6 and > the contents of the document and the list of authors? A quick > sentence about why the contributors are listed as such - rather than > as authors or in the acknowledgments - would be helpful. > > 2 I think it should be made clear whether the term "SAVI" refers to > "FCFS SAVI" or, more generally, to any form of SAVI throughout the > document. Section 2.6, for example, is unclear about the use of > "SAVI". It's important to be clear in section 2.6 because in my > opinion a SAVI perimeter could be composed out of various kinds of > SAVI functions. > > 3. What is the definition of a "realm"? It's important to define > realm because, by using ND to confirm the correctness of SAVI > bindings, the FCFS SAVI function only checks on the link to which it > is attached, not across the entire FCFS SAVI perimeter. > > 4. Also in section 3.2.3: > > NO_BIND > > o Upon the reception through a Validating Port (VP) of a Neighbour > Solicitation (NSOL) generated by the Duplicate Address Detection > (DAD) procedure (hereafter named DAD_NSOL) containing Target > Address IPAddr, the SAVI device MUST forward the NSOL and 250 > > In the last line, s/NSOL/DAD_NSOL/ How does the FCFS SAVI function > differentiate between NSOLs generated by DAD and other NSOLs? > > 5. In TENTATIVE state, section 3.2.3: > > the state remains in > TENTATIVE_DAD_NSOL, > > s/TENTATIVE_DAD_NSOL/TENTATIVE/ > > > > > > Russ Housley > > *Discuss (2011-05-26)* > > A quick read resulted in these concerns: > > - The majority of the document is about switch port mappings > although it says early on that this is not the only way to do > things. > > - The switch port mapping scheme implied by the unlabeled figure > on page 9 appears to allow a host connected to a switch outside > the perimeter to pretend to be any other host attached to the > switch without SAVI knowing differently as the packets come in > through the same 'protected' port. > > - Does the scheme work with multi-subnet links? If the subnets are > supported by different routers, then packets may go between routers. > This may work out, but nothing says one way or the other. Please > add some discussion. > > - Does the scheme work with multi-homed hosts? Again, there is no > discussion. Please add some discussion. > > *Comment (2011-05-26)* > > I support the DISCUSS positions offered by Ralph and Dan. > > > Stephen Farrell > > *Discuss (2011-05-23)* > > While this is quite long and maybe has some controversial things, it > doesn't impact that much on details of the actual scheme so I hope > it's less bad than it appears. > > (1) A general point about SAVI that also applies to SAVI FCFS: Since > SAVI is only about spoofed source addresses and is not about > monitoring hosts that never spoof anything, and since privacy is a > concern for the (I assume) huge majority of non-spoofing hosts I > would like to see this (and all SAVI standards track documents) say > something like: > > "Compliant implementations MUST NOT log binding anchor information > except where there is an identified reason (see section X for the > list of reasons applying for FCFS-SAVI) why that information is > likely to be involved in detection or prevention of actual source > address spoofing. Information that is not logged MUST be deleted as > soon as possible (see section Y for the conditions that make it safe > to delete information). Information about the majority of hosts that > never spoof SHOULD NOT be logged." > > The conditions for when logging is allowed and when each piece of > state can be deleted need to be specifically called out. Those would > be the putative sections X & Y in the above suggested paragraph above. > > I realise this may seem like a significant change (though not to the > parts of the protocol that actually detect spoofing) but I think it is > an important one. > > (2) Abstract - SAVI is not about the general "control of source > addresses used" - it is chartered to help detect/prevent source > address spoofing and that is all. > > (3) My phone can be a WiFi access point. How would that continue to > work if SAVI-FCFS were deployed? I think the document needs to say how > one can differentiate transit traffic from spoofed source addresses in > that case or that SAVI FCFS MUST NOT be used in networks that should > allow my phone to do its thing. 2.1 says that this technique only > applies to local traffic so implementers will need to know how to do > this. > > (4) I think SAVI FCFS needs a way to allow transit traffic and > disallow spoofed source addresses but that is not trivial to fool by > just pretending to be a router. If that is not possible, then this > technique just seems broken. Its not clear to me whether the spec has > this problem or not. > > (5) 2.4 - saying you "assume" that the binding anchor is a port on a > switched network implies that SAVI-FCFS MUST NOT be used in any other > case. You need to say that. On a related point, you need to clearly > say that this is just for IPv6 if that is the case, (depending on rfc > 4861 seems to make that the case). All text that implies that the > binding anchor for SAVI FCFS can be anything other than a port number > should also be excised since SAVI FCFS is only defined for the port > number being the binding anchor as far as I can see. This could > probably best be done via an applicability statement section at the > front. (Probably just a short paragraph is all that's needed.) > > (6) 2.5 I totally disagree that its a good idea for SAVI to log all > this information. I'd like to see the section removed. (And as in (1) > above, replaced with a MUST NOT for "normal" traffic and binding > anchor information.) > > (7) (If 2.5 ends up staying...) Where in the SAVI charter does it say > that "a secondary goal is to assist in traceability.."? Is there IETF > consensus for this goal? I don't believe there is. RFC 2804 would > imply the opposite. > > (8) If I end up in the rough on point (1) above, I would like to > discuss whether not not SAVI goals could be met while only dealing > with an anonymized form of binding anchor information. If so, then > maybe you should have a MUST for doing that where the binding anchor > information could be personally identifying. While this is less > relevant for SAVI-FCFS than perhaps other variants, (e.g. MAC address > or NAI) even a port can be personally identifying in a some networks. > > (9) The SAVI DB content says "such as the layer-2 address" but you've > gone to lengths to say that's not trustworthy so its presumably not > useful for detection of source address spoofing and should not be > included here. See also point (1) above - MAC addresses of > non-spoofing users should not be retained casually like this. I'd like > to see a statement that personally identifying data MUST NOT be > included in the SAVI DB with the MAC address as the canonical example. > (If packets do indicate attempted spoofing then I've no problem about > logging the MAC address.) > > (10) The prefix in the prefix list is v6 only - right? If so maybe > worth saying so. > > (11) 3.2.1 talks about what the SAVI device does when it boots - is > that the only time it is supposed to update the prefix list for > transit traffic? That seems wrong. > > (12) 3.2.2 uses the phrase "local prefixes" which doesn't seem to be > defined - does that cover prefixes for routers or not?` > > (13) 3.2.2 seems to say that transit traffic received on validating > ports is just dropped - that can't be right so maybe the text needs to > be rephrased to make it clear what happens. This may be related to > (12) above, but I find 3.2.2 just too hard to follow. > > (14) MLD is used without expansion and with no reference. > > (15) End of state machine, p17 - what does "P'==P''" mean here? > > (16) Why are the security considerations talking about the binding > anchor being a MAC address when you've ruled that out? The spec needs > to be clear about what binding anchor information can be used and not > discuss other possible binding anchor information types. > > [The next 3 are from the secdir review by Juergen Schoenwaelder.] > > (17) [secdir#1] > > My first question was triggered by text on page 8: > > [...] Before creating a SAVI binding in the local SAVI database, > the SAVI device will send a NSOL message querying for the address > involved. Should any host reply to that message with a NADV message, > the SAVI device that sent the NSOL will infer that a binding for that > address exists in another SAVI device and will not create a local > binding for it. > > Now, that sounded like it is easy to DoS new devices simply by > generating fake NADV messages. Later in section 3, it seems you only > accept NADV messages from trusted ports. If my reading is correct, > then a better wording might be: > > [...] Before creating a SAVI binding in the local SAVI database, > the SAVI device will send a NSOL message querying for the address > involved. Should any host _on a trusted port_ reply to that message > with a NADV message, the SAVI device that sent the NSOL will infer > that a binding for that address exists in another SAVI device and will > not create a local binding for it. > > But then I am not sure whether it is really practical to assume that > NADV messages always come from a trusted port. > > (18) [secdir#2] > > My second question concerns the construction of the prefix list. One > option is to learn prefixes by listening to Router Advertisements. Is > there a way to make SAVI do bad things by announcing bogus prefixes? > > (19) [secdir#3] > > My third question concerns this statement in the security > considerations: > > The other type of attack is when an attacker manages to create > state in the SAVI device that will result in blocking the data packets > sent by the legitimate owner of the address. In IPv6 these attacks > are not an issue thanks to the 2^64 addresses available in each link. > > The second sentence makes this sound like a non-issue but it seems to > be correct only if devices uniformly pick random addresses out of the > full 2^64 address space. If for whatever reason I can guess with a > decent likelihood an address, it looks like SAVI becomes a tool to > help me with denying service for such an address. > > (20) The "Security Logging" section should be changed significantly to > say that only suspected spoofing should be logged and that for privacy > reasons SAVI MUST NOT otherwise log normal use of the network. > > > *Comment (2011-05-23)* > > (1) I don't understand the sentence at the end of 2.1 " Manually > configured IPv6 addresses can be supported by FCFS SAVI, but manual > configuration of the binding on the SAVI device provides higher > security and seems compatible with manual address management." > > (2) 2.2 says that "non-compliant" packets can be dropped - there's no > IESG write-up so I'm wondering if this is safe or if there's any > evidence that this would be safe? Has this been implemented and if so > have any results of its effects been published? (I know that's not a > requirement for PS, but in this case, I think it would be very useful > information.) > > (3) 2.3 "prove address ownership" is too strong and I think ownership > is the wrong phrase in any case. > > (4) I don't understand "FCFS SAVI function relies on state information > binding the source address used in data packets to the binding anchor > that contained the first packet that used that source IP address." > Seems like it needs re-phrasing - "contained the first packet" is the > wrong bit. > > (5) The "it" in "CFS SAVI function relies on state information binding > the source address used in data packets to the binding anchor that > contained the first packet that used that source IP address" seems > ambiguous. I'm fairly sure it refers to each SAVI instance rather than > the set of instances in a SAVI perimeter but that should be made > clear. > > (6) State machine ascii art - expanding T.O. to timeout (I guess) > would be clearer. > > (7) "MLD considerations" - should you s/relay/rely/? > > (8) From section 4 on there are more English language errors that > should be fixed, e.g "The attacks against the SAVI device basically > consist on making the SAVI device to consume its resources until it > runs out of them" has two (and maybe 3) errors. There are also some > similar problems in Appendix A. (I have some marked up on paper so > easiest will be if I try to list any that remain if you rev. the I-D.) > > (9) [secdir review nits] > Editorial nits: > > - p10: s/because the connect/because they connect/ (twice) > - p10: s/through validating port/through validating ports/ > - p11: s/prefixes.A/prefixes. A/ > - p13: s/may due/may be due/ > - p13: s/packets has been/packets have been/ > - p18: s/relay/rely/ > - p24: s/coalition/collision/ > - p26: s/case fixed/case of fixed/ > > > Wesley Eddy > > *Discuss (2011-05-24)* > > Some questions I think the authors should respond to: > > I believe the RetransTimer is configurable in RFC 4861, so why is 250 ms a magic > number in Section 3.2.3 of this document? Are there scenarios where this value > needs to be configured differently or is this really one size fits all? I > didn't notice the motivation for this constant in the document, and it probably > should be explained. It seems to be fixed rather than just a default, but the > wording in this document is actually a little ambiguous about this. > > The same comment applies to TENT_LT (500 ms) and DEFAULT_LT (5 minutes). If > these constants are special for some reason and not just defaults that can be > tweaked to suit a deployment, it needs to be described why, otherwise the logic > for setting them a certain way needs to be given. > > *Comment (2011-05-24)* > > Some comments that I don't think are very important and that the authors should > feel free to either take or ignore: > > In section 2.1, second paragraph, it might make sense to be more clear that > routers use their own MAC address, but the packets that they forward have an > off-link source address that doesn't belong to them. However, I don't think > anyone will really be confused either way, so this is just a suggestion. > > > The definition of the term "binding anchor" is somewhat implicit in this > document. It might be a good idea to make it more explicit with just a sentence > or so more where it's first used in 2.3, and only one very brief example is > given. > > > In section 2.3, second paragraph, should "(e.g. the port in a switched LAN)" be > "(e.g. the MAC address and/or port in a switched LAN)"? From jmh@joelhalpern.com Mon May 30 07:13:31 2011 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 82780E068F for ; Mon, 30 May 2011 07:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 frOVi5Ejp+53 for ; Mon, 30 May 2011 07:13:29 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 68221E06C1 for ; Mon, 30 May 2011 07:13:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D34D54300EA; Mon, 30 May 2011 07:13:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-173.clppva.btas.verizon.net [71.161.51.173]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 9AB1D4300E5; Mon, 30 May 2011 07:13:26 -0700 (PDT) Message-ID: <4DE3A604.8080807@joelhalpern.com> Date: Mon, 30 May 2011 10:13:24 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jari Arkko References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> In-Reply-To: <4DE34147.8070103@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-savi-threat-scope@tools.ietf.org, SAVI Mailing List Subject: Re: [savi] Status of draft-ietf-savi-threat-scope 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, 30 May 2011 14:13:31 -0000 As I have said, i am happy to make most of the changes. However, there are two changes requested by Ralph that change the scope in a way that I do not feel I (or you) can call for. I have been awaiting the Chair's review on these two substantive issues: 1) The issue of analysis of the effect of SAVI, and what threats remain after SAVI was requested by Stephen. I pointed out that this is not in scope for the document, and he said that he wanted it anyway. I punted to you and the chairs. I believe it would take WG agreement, AD agreement on scope change, and chair direction, before I can make that change. 2) As you have been copied on, Stephen and I have been discussing the question of the references to logging, and the fact that it is likely to be used, and its utility is strengthened by the use of SAVI. This has been assumed to be significant by the working group. The charter however agrees with Stephen. Before I can make a change of that scope, it needs WG concurrence, as judged by the chair. It is the chair's task, as shepherd, to take these questions to the WG. I will try to get the other comments dealt with. I am not sure whether Ralph's request for "more details" is arelaly a discuss, or a suggestion to ask him for and consider more text. I am certainly willing to talk with him about it. But I would need to temper any such evaluation with the fact that folks asked us to CUT substantial portions of text in the last review. I have held off on that discussion because I wanted resolution on the other issues. I will contact Ralph this week. It was only on Sunday that I reached an understanding of what Stephen was asking for in point 2 above. Yours, Joel On 5/30/2011 3:03 AM, Jari Arkko wrote: > This draft was in IESG review last week. Please see below for the > comments that were raised. I would like the authors to correct these > issues and/or respond to the Discuss holders, as appropriate. There are > many detailed things, but the key takeaways that I took from my IESG > colleagues were the following: > > * Changes agreed after Gen-ART discussion need to be incorporated in a > new version of the document (Russ' Discuss) > > * Many of the issues around precise definitions and additional > information brought up by Ralph's Discuss seemed correct. Please ensure > that you adopt these in a new version as well. > > * I think you need to fix many of the details pointed to in Stephen's > Discuss, and explain that this document is not the one that will > describe what the residual threats are after SAVI is implemented. (That > would be the job of the individual SAVI mechanism documents). > > Jari > >> >> Dan Romascanu >> >> *Comment (2011-05-25)* >> >> I find the document comprehensive but I share DBH's observation that >> it's a >> little too verbose and could use some fixes in the details. >> >> Beyond what he found I have a few more observations. None is critical >> for this >> informational document, but cleaning up all these text unclarities in >> a new >> version would be recommended; >> >> 1. In the Glossary section >> >> NNI Router: Network to Network Interface Router. This router >> interface faces a similar system operated by another ISP or other >> large network. >> >> I think that the definition should read something like 'A router with >> interfaces >> facing a similar system ...' >> >> 2. Section 4.2.3.3 >> >> IEEE 802.1x is an authentication protocol that permits a network to >> determine the identity of a system seeking to join it and apply >> authorization rules to permit or deny the action. In and of >> themselves, such tools confirm only that the user is authorized to >> use the network, but do not enforce what IP address the user is >> allowed to use. It is worth noting that elements of 802.1x may well >> be useful as binding anchors for SAVI solutions. >> >> This is quite confusing. IEEE 802.1X is a port (in the sense of bridge >> or layer >> 2 switch) access control standard that controls the joining of devices >> to a >> layer 2 bridged network. The term 'tools' is not in place and there is >> nothing >> about the 'user' in the protocol itself but about the device - the >> standard uses >> the term 'supplicant' which is rather the device or the piece of software >> running on the device that presents credentials to an authenticator. >> >> 3. In section 5.2 'hosts connected to switch ports that may have one >> or more IP >> addresses' is probably rather 'hosts that may have one or more IP >> addresses >> connected to (layer 2) switch ports' >> >> >> David Harrington >> >> *Comment (2011-05-23)* >> >> I found this document to be very informative about the problem space. >> I think >> this document could have been far more effective if the text didn't >> meander >> around the points it was trying to make; it could habve been far more >> succinct. >> Here are some suggestions that I think could improve the document. >> >> 1) I find the following ambiguous, "the operational staff needs to be >> able to >> track from the IP address sourcing the attack to the particular >> machine within >> the enterprise that is the source. " I think the intention is that >> "the IP >> address sourcing the attack" means the spoofed address, and "that is >> the source" >> means the actual sending machine, but I'm not sure. This can be read >> as "the >> staff needs to track from the source to the source." >> 2) This sentence doesn't >> parse properly, "This both that the information be useable ..." I >> think the >> sentence is missing "means" or "requires" or something. >> 3) The glossary should >> include references to the defining documents. >> 4) "or order to disrupt" -> "in >> order to disrupt" >> 5) 3.1.3 doesn't describe what a poison attack is. It also >> refers to "the same kinds of poisonings as above", but above never >> spoke of >> poisoning attacks. >> 6) the following seems a bit perverted logic - a malware >> attack is important because it is a justification for SAVI? >> "This attack is >> important both in terms of an attack vector that SAVI may help >> prevent, and also >> as a problem which SAVI can help track back to find infected systems. " >> Shouldn't you be arguing that savi is important for preventing these >> types of >> attacks? 7) section 3.2.2 "Another example of sighted attack" - this >> is the >> first mention of "sighted attack". Please use consistent terminology. >> 8) in >> section 3.2.2, "The use of spoofed addresses, while not necessary for >> this, can >> often provide additional information, and helps mask the traceability >> of the >> activity." would seem to be the conclusion of the paragraph, but this >> precedes >> the discussion of what the attack is. >> 9) in scetion 4, "the first requirement" >> isn't followed by any further requirements. and is this section going to >> describe the requirements or the solutions? >> 10) "The IP source address is >> appropriate for the lower layer address (they both identify the same >> system)". >> I find "is appropriate" too ambiguous, although the following >> parethetical text >> explains it. I suggest this would be better written as "the IP source >> address >> and the lower layer address both identify the same system." >> 11) "The IP source >> address is appropriate for the device at the layer 2 switch port" I >> find "is >> appropriate" too ambiguous. " (the address was assigned to a, and >> perhaps the, >> system that uses that port) " doesn't parse appropriately. I think >> this bullet >> needs a better description. >> 12) section 4.1.1 "Port identification prevents >> transmission of malicious datagrams" Is thistrue? or is port >> identification one >> method that can be used to help prevent transmission? 13) 4.1.3 "An >> obvious >> special case of the discussion is with an ISP PE router, " - what >> discussion? >> This section seems based on speculation about possible solutions, >> including >> contract negotiations. I think this would be much better if it >> actually focused >> on technical solutions for validating addresses for ISP edge routers. >> 14) 4.1.4 >> again discusses business agreements between two conpanies. Please >> focus on >> ***technical*** solutions at this topological location. >> 15) 4.1.4 "However, when >> it can be shown that spoofed addresses are present, the procedure can be >> applied. " what procedure? >> 16) 4.2.5 is entitled residual attacks, but there is >> no discussion of residual attacks in the paragraph. The hand-waving >> contained in >> the paragraph doesn't seem worth documenting. >> 17) why is 4.2.5, "residual >> attacks", included in section 4 "Current anti-spoofing solutions"? >> 18) 5.2.6 >> what does "proper member" mean? where is this defined? >> 19) 5.2.7 - doesn't this >> sum up the whole section 5? since it includes anything not covered in >> 5.1 or >> 5.2, shouldn't this be 5.3? >> 20) is 5.3 about topological challenges? it seems to >> meander on about additioonal capabilites, rather than discussing the >> topological >> challenge to SAVI. >> >> >> Peter Saint-Andre >> >> *Comment (2011-05-23)* >> >> Please expand "DoS" on first use and add an informational reference to >> RFC 4732. >> >> >> Russ Housley >> >> *Discuss (2011-05-24)* >> >> The Gen-ART Review by David Black on 12-May-2011 lead to a discussion >> with one of the authors. At the end of the discussion, several >> changes to the document were agreed. However, those changes have >> not been made. >> >> >> Stewart Bryant >> >> *Comment (2011-05-23)* >> >> A useful document which I enjoyed reading >> >> >> Wesley Eddy >> >> *Comment (2011-05-24)* >> >> The document looks good, I just have a few comments that the authors >> might think >> about: >> >> Section 3.1.7 is titled "other blind spoofing attacks" but talks about >> non-blind >> attacks just as much. The example given of a host on-link with routers >> is non- >> blind, for instance. However, seciton 3.2 is where non-blind attacks are >> supposed to be discussed, so this part of 3.1.7 seems rather odd. >> >> >> Why isn't the relationship to SeND discussed in this document? >> >> >> VPN gateways have similar considerations as the Mobile IP HA in >> sectino 5.2.6, >> but VPN gateways don't appear to be discussed in 5.2. >> >> >> Ralph Droms >> >> *Discuss (2011-05-25)* >> >> I will raise a meta-discussion issue before listing several specific >> Discuss points. This issue may be just the suppressed pedantic >> ex-professor side of my personality expressing itself. My issue is >> that the contents of this document are useful and not incorrect. >> However, in my opinion the document would be more useful, especially >> to someone who reads this document without a lot of background in the >> type of threats described, with some additional detail. I could be >> persuaded that I am being overly pedantic, in which case I will clear >> my Discuss and move my points to Comments. I will be happy to send >> text if the authors would find it helpful. >> >> 1. In section 1: >> >> At the IP Network Layer, or Internet Layer, there is typically no >> required transactional state when communicating with other hosts on >> the network. Hosts generating packets for transmission have the >> opportunity to spoof (forge) the source address of packets which they >> transmit. >> >> I think this paragraph needs more detail to connect the first sentence >> with the last sentence. >> >> 2. Next paragraph: >> >> Source address verification is necessary in order to detect and >> reject spoofed packets and contribute to the overall security of IP >> networks. In particular, source address verification techniques >> enable detection and rejection of spoofed packets, and also >> implicitly provide some assurances that the source address in an IP >> packet is legitimately assigned to the system that generated the >> packet. >> >> "Source address verification" can be used or is necessary? You >> haven't told us what source address verification is, yet. The second >> sentence in this paragraph doesn't seem to add any new information. >> What would be more helpful would be a sentence or two foreshadowing >> the details in section 3. Why are packets with spoofed addresses >> dangerous? >> >> 3. The attacks in section 3 fall, roughly, into two buckets: those that >> require spoofed source addresses and those that can use spoofed >> addresses to obfuscate the source of the attack. SAVI can eliminate >> the former but only deter, through threat of discovering the >> perpetrator, the latter. The difference is important to someone using >> this document to learn about how SAVI contributes to security in a >> network. Otherwise, a network administrator might expect to eliminate >> all of the listed attacks with SAVI. >> >> An improvement would be to explain the two types of attacks and >> indicate the type of the attacks in section 3. >> >> 4. I found the second sentence of the first paragraph of section 4 >> very hard to parse and not entirely consistent with the title of the >> section. While most of the solutions in section 4 have to do with the >> network topology, the first bullet: >> >> o The IP source address is appropriate for the lower layer address >> (they both identify the same system) >> >> has nothing to do with network topology. >> >> The second bullet: >> >> o The IP source address is appropriate for the device at the layer 2 >> switch port (the address was assigned to a, and perhaps the, >> system that uses that port) >> >> does use network topology, but seems specific to wired networks; in >> fact, later in section 4, wireless networks are mentioned as using >> different techniques. Might be better to write: >> >> o The IP source address is explicitly identified as appropriate >> for the physical topology; for example, the source address >> is appropriate for the layer 2 switch port through which the >> datagram was received >> >> 5. Section 4.1.1 changes in mid-section from checking the IP address >> against the Link Layer address to checking the IP address against the >> physical attachment point. Is Link Layer address checking ever >> implemented on switches or is it always IP address checking versus the >> physical attachment point? >> 6. I suggest augmenting section 4.1.3 with a mention of IPv6 prefix >> checking, where the PE can be populated with the customer prefix >> through monitoring DHCPv6 prefix delegation. >> >> Also, the enterprise case can be augmented with prefix filtering based >> on the prefixes known by the ISP to be assigned to the customer. >> >> 7. Sections 4.1.5 either needs more detail or pointers to references >> where more detail is available. In its current form, it has little >> or no content. The interesting parts of DOCSIS are the authentication >> and trust model, in which the ISP can control and trust the cable >> modem. >> >> 8. Section 4.1.6 has more detail than section 4.1.5, but assumes some >> experience with DSL deployments and architectures. Both of these >> sections would benefit from some explanation of the accountability >> model in which packets can be traced to an accountable entity, >> regardless of the specific address or prefix in the source address of >> a packet. >> >> 9. Section 4.2.3.2 might benefit from just a little more detail, or a >> pointer to more detail: >> >> switch uses IP address to port binding >> switch enforces restrictions that DHCP server traffic is only >> accepted from "upstream" >> switch monitors DHCP traffic to glean address-port bindings >> >> This technique works for both IPv4 and IPv6. >> >> And, the discussion of SLAAC brings up the issue of authenticated SAVI >> versus "ad hoc" SAVI. In the case of DHCP based SAVI, the switch can >> have authoritative information about the address/port binding, because >> it came from a reliable source (DHCP server). SLAAC-based SAVI can >> only identify claimed addresses, where the hose may not be authorized >> to use the claimed address. >> >> 10. Are the techniques mentioned in 4.2.4 really SAVI? >> >> 11. What is a "residual attack" and how does the text in section 4.2.5 >> describe a residual attack? >> >> *Comment (2011-05-25)* >> >> 1. Add DoS (yeah, I know DoS is pretty widely used already), "binding >> anchor" (and use "binding anchor" through the document), MITM, LAND, >> smurf attack, uRPF to section 2. Some of these also have first-use >> expansion, which might be OK ... this suggestion is just a Comment. >> >> 2. Suggestion: it would be more useful to incorporate any issues >> specific to IPv6 in the body of the document. >> >> 3. First sentence of section 4: >> >> The first requirement is to eliminate datagrams with spoofed IP >> addresses from the Internet. >> >> First requirement for what? I thought this document was exactly about >> "eliminat[ing] datagrams with spoofed IP addresses from the Internet." >> I suggest dropping the sentence. >> >> 4. At the end of section 4, the bullet list calls out "enterprise CPE >> Router" explicitly. Aren't residential CPE routers also a big >> opportunity? How are they different from enterprise CPE routers. In >> fact, perhaps "CPE" is not the best term? How about "Enterprise edge >> router" and add "subscriber home router"? >> >> 5. At the end of section 1, have the strength of your convictions: >> >> This document provides [...], and discusses [...]. >> >> 6. For consistency, in sections 3.2.1 and 4.1.1 >> s/MAC address/Layer 2 address/ >> 7. Is "source address verification" equivalent to "Source Address >> Validation Improvement (SAVI)"? If so, for consistency use one phrase >> or acronym throughout. >> >> >> Stephen Farrell >> >> *Discuss (2011-05-26)* >> >> (1) What's the difference between "validation" (abstract) and >> "verification" (overview, 3rd para) as used here? If there is >> none, then just use one. If this is a difference, then where are >> these defined? I think in either case, some definition is needed. >> >> (2) I expected this document to also analyse source-address >> spoofing threats after SAVI mechanisms are deployed. If some simple >> form(s) of source address spoofing will work regardless of which >> SAVI mechanism(s) are in place then one would have to wonder if >> SAVI is worth deploying or not. If this is not the right document >> to cover that then what is? The fact that the SAVI mechanisms will >> each be in separate documents would seem to mean that this question >> won't otherwise be answered by the WG, and I think we do need an >> answer somewhere. (The security considerations of the SAVI >> framework is currently one paragraph so that's not the place, at >> least not now.) Its probably worth noting that this issue is behind >> a number of cases below where I ask for evidence to justify what >> appear to be overly broad claims made. >> >> (3) What is the evidence that "Source address verification is >> necessary in order to detect and reject spoofed packets"? I'm >> asking why this is "necessary"as opposed to sufficient (if it is >> sufficient - see (2) above). >> >> (2) This presumably needs some form of qualification if not all >> packets with spoofed source addresses can be spotted: "source >> address verification techniques enable detection and rejection of >> spoofed packets." I'm not sure if "some spoofed packets" would be a >> good thing to say there but it does seem to be the case - a better >> qualification (or a forward reference to where that is described) >> would represent truth-in-advertising. >> (3) Where in the charter is "local traceability" in scope? The >> charter does say that "tracking other protocols is not in scope" so >> local traceability needs to be defined as something limited >> to/scoped to spoofed source addresses. >> >> (4) "For example, when an enterprise receives a report of an attack >> originating within that enterprise, the operational staff needs to >> be able to track from the IP address sourcing the attack to the >> particular machine within the enterprise that is the source." I >> don't think that's true in general - "needs" is wrong since there >> can be other ways to find a zombie. >> >> (5) Spoofing is defined to cover both IP and MAC address spoofing. >> SAVI does not address the latter I believe (right?). If so, then I >> think you need to separate these as otherwise confusion between >> them might lead to incorrect conclusions being stated. Spoofing is >> also defined as "forging" but that is not defined and could be >> considered to be synonymous with "spoofing" here which would make >> this a circular definition. I think the definition of spoofing >> needs to be more precise basically. >> >> (6) 3.1: " The result is that they have no access to legitimate >> source and target systems." I think that's wrong - are you trying >> to say that "The attacker in this case should have no legitimate >> access to source and target systems." >> (7) Does the ARP example in 3.2.1 really involve a spoofed IP >> source? If not, then you should note that its not in scope for >> SAVI. If it is, then say why its in scope. >> >> (8) I'd be interested in knowing if SAVI can help with 3.2.2 - if >> not then saying so would be right. If so, then saying when SAVI >> might help would be good. >> >> (9) If "The first requirement is to eliminate datagrams with >> spoofed IP addresses from the Internet." then SAVI would seem to be >> facing an impossible problem. The "can eliminate such datagrams" >> part also seems overstated - where's the evidence that that's true? >> s/eliminate/reduce/ would seem to be more correct. >> (10) Saying that "Internet devices can...confirm...that the IP >> address is appropriate for the lower layer address" is not true of >> all "Internet devices" only for some near the source, so that's >> also overstated and needs to be qualified. (It is later to be fair >> but the statement itself is wrong.) >> >> (11) I don't know the answer here, so this is just a question - >> what is the likelihood the uRPF check works well? (I didn't find >> the string uRPF in RFC 3704, so I'm not sure, but I didn't really >> read 3704;-) I guess the real question is whether a failure in uRPF >> might break anything for a non-spoofing host and whether a spoofing >> host could make it so that uRPF checks allow the packet with a >> spoofed address through (from e.g. the same subnet, or for certain >> guessable source addresses). I ask (in part) since 4.2.2 says that >> uRPF is a crude mechanism. >> >> (12) I'm not sure whether 4.1.3 and 4.1.4 are in or out of scope >> for SAVI. Can you make that clear? >> >> (13) What does "unforgeable" mean in 4.2.3? Perhaps you need to >> define that term as well? It may be that the meaning differs for >> e.g. MAC addresses and other credentials (noting that passwords can >> be guessed or shared of course). >> (14) In 4.2.3 where is the evidence that "a large portion of the >> ...threat space...can be marginalized" - I think that needs some >> qualification. >> >> (15) 4.2.3.2 says that DHCP and sniffing "can...auotmatically >> provide sufficient binding information" - is there evidence for >> that somewhere? Be good to reference it. >> >> (16) 802.1X determines the identity of a user, not a system I >> think. >> >> (17) I think 4.2.5 needs to better characterise the "residual >> threat" (not "residual attack") - for each of the various forms of >> SAVI. I had hoped this document would say what spoofing >> possibilities remain. Providing just one example doesn't seem >> sufficient. >> >> (18) Section 6 (at least) should also recognise that there are >> privacy considerations that apply and that more-or-less directly >> run counter to the ability to trace the source of problems. >> >> (19) Section 8 should note that circumstantial evidence linking a >> person to an IP address can be dangerous for the person. There have >> been cases where such tracking has mis-identified people >> responsible for some act. (I don't have a reference to hand sorry.) >> >> (20) If no set of deployed SAVI instances can prevent all spoofing >> from a given network then an attacker could probe the network to >> find out what spoofing works from where they are at, and then use >> that. Success in spoofing would then likely have more consequences >> for an innocent spoofed party. This would be a new threat caused by >> SAVI itself. >> >> (21) If binding anchors are personally identifying or stable over >> time or location then recording those creates new threats for tracking >> the user or host associated with the binding anchor. That needs to be >> noted. >> >> *Comment (2011-05-26)* >> >> (1) 2nd para of overview says that there is "typically no required >> transactional state when communicating with other hosts on the >> network." I think it'd be good to say why that's the case, via a >> reference to something. (Not sure what reference is best exactly.) >> >> (2) What is a "better Internet participant"? It sounds like a scary >> thing. >> >> (3) s/This both that the information be useable/This requires both >> that the information be useable/ >> >> (4) I expected to see some CVE references in section 3 but didn't >> see any. I'd encourage adding some of those for each of the threats >> covered since that should help motivate the work and would >> demonstrate that there are real threats to mitigate. (E.g. a quick >> search on "CVE spoofed source" throws up a bunch.) To take one >> example, 3.1.4 could do with such a reference. >> >> (5) Expand "LAND" >> >> (6) The DNS attack described around the top of page 9 isn't >> relevant to SAVI, right? Maybe the smurf attack is enough there. >> >> (7) Do 3.1.6 and 3.1.7 really fit in 3.1? >> (8) Do *all* CMTS employ DOCSIS? 4.1.5 says that they do. >> >> (9) Even IPsec doesn't unquestionably verify source address if >> load-balancing is in place with private key sharing. > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jmh@joelhalpern.com Mon May 30 07:18:40 2011 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 382FEE078B; Mon, 30 May 2011 07:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 EpTJFFCKGdao; Mon, 30 May 2011 07:18:39 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id 68627E068F; Mon, 30 May 2011 07:18:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6230A4300B7; Mon, 30 May 2011 07:18:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-173.clppva.btas.verizon.net [71.161.51.173]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id 9580643009C; Mon, 30 May 2011 07:18:38 -0700 (PDT) Message-ID: <4DE3A73C.7010504@joelhalpern.com> Date: Mon, 30 May 2011 10:18:36 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Jari Arkko References: <20110526184022.21773.97885.idtracker@ietfa.amsl.com> <4DE3441E.6000801@piuha.net> In-Reply-To: <4DE3441E.6000801@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-savi-fcfs@tools.ietf.org, SAVI Mailing List , IESG Subject: Re: [savi] Status of draft-ietf-savi-fcfs 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, 30 May 2011 14:18:40 -0000 This change represents a major change in the assumptions of the working group. Stephen is correct that the charter takes the view he espouses on this. But I would like to see discussion on the WG mailing list, with agreement by the WG to a change of this scope, rather than merely having the ADs decide how to solve the issue. (I suspect that given the charter, the resolution will be the one requested. But this is simply too central to the work for the IESG to direct the change.) Yours, Joel On 5/30/2011 3:15 AM, Jari Arkko wrote: > This draft was in IESG review last week.... > * You should make the changes suggested by Stephen to avoid privacy > impacts of unnecessary logging information from this technology ... From jmh@joelhalpern.com Mon May 30 08:05:33 2011 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 A3A11E07DF for ; Mon, 30 May 2011 08:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 6rKvGlwY71cE for ; Mon, 30 May 2011 08:05:32 -0700 (PDT) Received: from hermes.out.tigertech.net (hermes.out.tigertech.net [74.114.88.72]) by ietfa.amsl.com (Postfix) with ESMTP id E4C83E07DC for ; Mon, 30 May 2011 08:05:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id DDA4E4300CB; Mon, 30 May 2011 08:05:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-173.clppva.btas.verizon.net [71.161.51.173]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTPSA id E6F634300C3; Mon, 30 May 2011 08:05:31 -0700 (PDT) Message-ID: <4DE3B239.10706@joelhalpern.com> Date: Mon, 30 May 2011 11:05:29 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: SAVI Mailing List References: <20110526184022.21773.97885.idtracker@ietfa.amsl.com> <4DE3441E.6000801@piuha.net> <4DE3A73C.7010504@joelhalpern.com> <4DE3A84E.6010406@cs.tcd.ie> In-Reply-To: <4DE3A84E.6010406@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Stephen Farrell Subject: Re: [savi] Status of draft-ietf-savi-fcfs 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, 30 May 2011 15:05:33 -0000 Thank you Stephen. I think that in resolving this the working group needs to keep in mind two facts. 1) The vast majority of implementations will perform such logging, whether we tell them to or not; 2) that it is actually helpful in refuting claims that IPv6 can not address various issues to have the logging available for citation. On the other side, not only is the charter more narrow, but encouraging such logging does represent a threat to privacy, and that can not be ignored. Yours, Joel On 5/30/2011 10:23 AM, Stephen Farrell wrote: > > FWIW, I agree with Joel, the WG needs to figure this one out > I think, otherwise we may hit the same or a similar discuss > on multiple documents. As I said in an offlist mail to Joel, > I'm happy to try help with that to the extent that that's > useful, so folks should feel free to ping me if they want. > > Cheers, > S. > > On 30/05/11 15:18, Joel M. Halpern wrote: >> This change represents a major change in the assumptions of the working >> group. Stephen is correct that the charter takes the view he espouses >> on this. But I would like to see discussion on the WG mailing list, >> with agreement by the WG to a change of this scope, rather than merely >> having the ADs decide how to solve the issue. (I suspect that given the >> charter, the resolution will be the one requested. But this is simply >> too central to the work for the IESG to direct the change.) >> >> Yours, >> Joel >> >> On 5/30/2011 3:15 AM, Jari Arkko wrote: >>> This draft was in IESG review last week.... >> >>> * You should make the changes suggested by Stephen to avoid privacy >>> impacts of unnecessary logging information from this technology >> ... > From jari.arkko@piuha.net Mon May 30 08:46:22 2011 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 03C4CE07F3; Mon, 30 May 2011 08:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 RDbHQJJPGGZw; Mon, 30 May 2011 08:46:21 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 4E30FE07ED; Mon, 30 May 2011 08:46:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1ADEA2CC49; Mon, 30 May 2011 18:46:18 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVNPuR1PdrmN; Mon, 30 May 2011 18:46:17 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 085FC2CC2F; Mon, 30 May 2011 18:46:17 +0300 (EEST) Message-ID: <4DE3BBC8.70206@piuha.net> Date: Mon, 30 May 2011 18:46:16 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "Joel M. Halpern" References: <20110526184022.21773.97885.idtracker@ietfa.amsl.com> <4DE3441E.6000801@piuha.net> <4DE3A73C.7010504@joelhalpern.com> In-Reply-To: <4DE3A73C.7010504@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-savi-fcfs@tools.ietf.org, SAVI Mailing List , IESG Subject: Re: [savi] Status of draft-ietf-savi-fcfs 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, 30 May 2011 15:46:22 -0000 Joel, > But I would like to see discussion on the WG mailing list, with > agreement by the WG to a change of this scope, rather than merely > having the ADs decide how to solve the issue. Yes, exactly. That's one of the reasons I sent my mail to the working group, as opposed to just trying to find agreement with the author team as we sometimes do for some Discusses. I do realize that there might be different opinions on this. I did not fully realize that the working group had made a major assumption about it. In any case, we should discuss this. I also wanted to remind everyone that on these types of matters we'd normally want to find what the opinion of the working group and IETF community is. Sometimes it happens that the community will disagree with an AD who holds a Discuss, and that would typically be enough to remove the Discuss. In other words, you should not take this or any other Discuss from the ADs as an absolute requirement. We should do what the community thinks is best. FWIW I do think personally that we should discourage excessive logging. Stephen's suggestions for the changes sound good to me. Jari From jari.arkko@piuha.net Mon May 30 08:55:20 2011 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 4ACFBE06A2 for ; Mon, 30 May 2011 08:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 3obdopksLFEj for ; Mon, 30 May 2011 08:55:19 -0700 (PDT) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id C55D2E0795 for ; Mon, 30 May 2011 08:55:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1C8162CC49; Mon, 30 May 2011 18:55:17 +0300 (EEST) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZE6ZbBTpv7n; Mon, 30 May 2011 18:55:16 +0300 (EEST) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 5BD282CC2F; Mon, 30 May 2011 18:55:16 +0300 (EEST) Message-ID: <4DE3BDE4.2040909@piuha.net> Date: Mon, 30 May 2011 18:55:16 +0300 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: "Joel M. Halpern" References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> In-Reply-To: <4DE3A604.8080807@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-savi-threat-scope@tools.ietf.org, SAVI Mailing List Subject: Re: [savi] Status of draft-ietf-savi-threat-scope 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, 30 May 2011 15:55:20 -0000 Joel, > As I have said, i am happy to make most of the changes. > However, there are two changes requested by Ralph that change the > scope in a way that I do not feel I (or you) can call for. > I have been awaiting the Chair's review on these two substantive issues: > > 1) The issue of analysis of the effect of SAVI, and what threats > remain after SAVI was requested by Stephen. I pointed out that this > is not in scope for the document, and he said that he wanted it > anyway. I punted to you and the chairs. I believe it would take WG > agreement, AD agreement on scope change, and chair direction, before I > can make that change. My opinion is that this document should NOT do that analysis or attempt to find out precisely what residual threats are after some set of SAVI tools have been implemented in a network. I think we touched upon it in the call, but I can talk to Stephen about it. > I am not sure whether Ralph's request for "more details" is arelaly a > discuss, or a suggestion to ask him for and consider more text. I am > certainly willing to talk with him about it. But I would need to > temper any such evaluation with the fact that folks asked us to CUT > substantial portions of text in the last review. OK. Its certainly bit of a borderline as a discuss. He wants more precise description and in some cases more text. From my read many of the points that he makes seemed reasonable. If I was the author I would go through his specific requests and see which ones made sense (while remembering the feedback you've gotten from other folks). You do not have to implement verbatim everything that the IESG reviewers ask for. Please fight back if the requests do not make sense. I thought I was asking for that, actually. Jari From stephen.farrell@cs.tcd.ie Mon May 30 07:23:17 2011 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 5C5D2E068F; Mon, 30 May 2011 07:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.033 X-Spam-Level: X-Spam-Status: No, score=-105.033 tagged_above=-999 required=5 tests=[AWL=1.566, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 PG1AUreVIX25; Mon, 30 May 2011 07:23:16 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 48DD2E07C9; Mon, 30 May 2011 07:23:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B0B4A171C54; Mon, 30 May 2011 15:23:15 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1306765395; bh=dWEEXcdon+giSu COqSaiBotTlijzD742XTdG6SGvYtE=; b=xbjDJAwmktLGfsvVkpDMTwcfbO7kZt 1UG2mZHk2gP20q6rp6Wgj1YmJwS4gFgHw/gjVdk3cJca8PV076wF1EamKVPEiNU0 Lsmrphi7s0fUpWKRlYinX7mt+hy7Lxr3IxR7tI6+tMDH+G1ByYgpyPGSVzpTUwm/ NYrmBg7QttY9+uefOria6Q3YvOWf68MzmIhLSR4Fvt+NJbPsQ4l4CSlxq1SOrqyH DrZYKHEyc5rolf5xddsshTK1tDCpxvTyqEY0TDDhgUZj5PA8PufPmas/gRiCJH7L foiq/e6n0sd5FhTarKKzLTAOnMgMuskH+Wm7nz5F7Bs3pZ1ddVpre6cQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id V3y8QiWOuHWn; Mon, 30 May 2011 15:23:15 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6E9DF171C01; Mon, 30 May 2011 15:23:11 +0100 (IST) Message-ID: <4DE3A84E.6010406@cs.tcd.ie> Date: Mon, 30 May 2011 15:23:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "Joel M. Halpern" References: <20110526184022.21773.97885.idtracker@ietfa.amsl.com> <4DE3441E.6000801@piuha.net> <4DE3A73C.7010504@joelhalpern.com> In-Reply-To: <4DE3A73C.7010504@joelhalpern.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 31 May 2011 07:50:08 -0700 Cc: draft-ietf-savi-fcfs@tools.ietf.org, IESG , SAVI Mailing List Subject: Re: [savi] Status of draft-ietf-savi-fcfs 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, 30 May 2011 14:23:17 -0000 FWIW, I agree with Joel, the WG needs to figure this one out I think, otherwise we may hit the same or a similar discuss on multiple documents. As I said in an offlist mail to Joel, I'm happy to try help with that to the extent that that's useful, so folks should feel free to ping me if they want. Cheers, S. On 30/05/11 15:18, Joel M. Halpern wrote: > This change represents a major change in the assumptions of the working > group. Stephen is correct that the charter takes the view he espouses > on this. But I would like to see discussion on the WG mailing list, > with agreement by the WG to a change of this scope, rather than merely > having the ADs decide how to solve the issue. (I suspect that given the > charter, the resolution will be the one requested. But this is simply > too central to the work for the IESG to direct the change.) > > Yours, > Joel > > On 5/30/2011 3:15 AM, Jari Arkko wrote: >> This draft was in IESG review last week.... > >> * You should make the changes suggested by Stephen to avoid privacy >> impacts of unnecessary logging information from this technology > ...