From jeanmichel.combes@gmail.com Mon Jun 6 06:42:05 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 4D68811E8140 for ; Mon, 6 Jun 2011 06:42:05 -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 E20W4bOdlco9 for ; Mon, 6 Jun 2011 06:42:04 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9C811E811E for ; Mon, 6 Jun 2011 06:42:04 -0700 (PDT) Received: by gyf3 with SMTP id 3so1995724gyf.31 for ; Mon, 06 Jun 2011 06:42:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=CNkYjTZcUcD8e8KfmGQTGMOi1cTzkAfxCHtynkJLFTc=; b=bGiG+mGStu1SAqBiHx1pQJTfUTOdfpk6NKEVBHjsm+5qx0+Tlb+5zU5TS3zSpfy9xp IhZ/iff6hXWX0U14CoYuTyH3qnuOOvd4rGXRTmau/jtxTeC1PyolN6pd0ISmn1ZcCY5I fvaeZ+kwy3aGlc+7qs6E76kAIDvfKWFzd1rgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=tk2TeX+WUpEMYxltGCw8RlYqNivuu+kFnjbZjGYsyD+eIWMJxoztIgiZWE7k3QL43N spRRXQFTavo5Q8208+0ozBKclZXOVwsbFphUw6eJ1lWl6Xtgywelz5EmyBNQlQcsghsy U/02MrtcqoPQECqphO+ngi0MYM3TMbFijhQSk= MIME-Version: 1.0 Received: by 10.147.131.10 with SMTP id i10mr1517885yan.37.1307367724050; Mon, 06 Jun 2011 06:42:04 -0700 (PDT) Received: by 10.147.125.3 with HTTP; Mon, 6 Jun 2011 06:42:04 -0700 (PDT) Date: Mon, 6 Jun 2011 15:42:04 +0200 Message-ID: From: Jean-Michel Combes To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: int-ads@tools.ietf.org, Christian Vogt Subject: [savi] Call for WG items for a potential rechartering 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, 06 Jun 2011 13:42:05 -0000 Folks, As promised during the last SAVI meeting in Prague, to prepare the next IETF meeting, I would like to know whether WG members believe there are still open issues the WG needs to work on or not. If so, please, reply to this email, providing a clear description of the item and your contribution (i.e. Editor, Co-Author, Reviewer). For each proposed item, at least three volunteers ready to review the future document are requested. If you believe the WG has finished the work and can be closed, don't hesitate to tell it too. The deadline to reply is 2011-06-20. Thanks in advance. Best regards. JMC. From jeanmichel.combes@gmail.com Wed Jun 8 10:28: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 DE3A711E8076 for ; Wed, 8 Jun 2011 10:28:33 -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 CNKRxJ83d2LC for ; Wed, 8 Jun 2011 10:28:33 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D686C11E8104 for ; Wed, 8 Jun 2011 10:28:32 -0700 (PDT) Received: by gxk19 with SMTP id 19so417976gxk.31 for ; Wed, 08 Jun 2011 10:28:32 -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:cc:content-type :content-transfer-encoding; bh=fvEo1j4hw1iKvDriYcLIl9agU58KikUXwRJ9wfHzDIk=; b=Zld81oAHhYKw1nVZ1Lx/0z9NGf9cic9pMlwzBV0hU0W18eFhmUQ+YVczPnyYbIar+G eq8DI4Mt2BHEqUsLsTZxpPzDZ54qavf6rHJcQq9GlhxI9HjZjQH1gp5zXS4nWjrLk++r 00Q27lG4dT5e2p/0DxfAtJahCsM1H2gWhAXHE= 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 :cc:content-type:content-transfer-encoding; b=UPaxvy+HhJ5qYFWNC/IISTAwRcttfkY2H6aRP516Fco4QzDcfLnn88KzEoPaBC9fge HVeAt38Y9qPW7OlKLvB3XvLuLU2Qv9Rs0KH5l3xtK29mpQxpwUNAoVsgo5lqR2BrbYFn Rhrn8HYV8D2loDQU32zmug91j0iulyFAPR18M= MIME-Version: 1.0 Received: by 10.236.182.233 with SMTP id o69mr2777077yhm.30.1307554111809; Wed, 08 Jun 2011 10:28:31 -0700 (PDT) Received: by 10.147.125.3 with HTTP; Wed, 8 Jun 2011 10:28:31 -0700 (PDT) In-Reply-To: <4DE3BDE4.2040909@piuha.net> References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> <4DE3BDE4.2040909@piuha.net> Date: Wed, 8 Jun 2011 19:28:31 +0200 Message-ID: From: Jean-Michel Combes To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SAVI Mailing List , draft-ietf-savi-threat-scope@tools.ietf.org 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: Wed, 08 Jun 2011 17:28:34 -0000 Hi, At first sorry for the delayed reply. Please, see my comments inline. 2011/5/30 Jari Arkko : > 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. =A0I pointed out that this is not i= n >> scope for the document, and he said that he wanted it anyway. =A0I punte= d to >> you and the chairs. =A0I believe it would take WG agreement, AD agreemen= t 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 t= o > 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 cal= l, > but I =A0can talk to Stephen about it. I agree with Jari: (1) IMHO, this would be like to put the cart before the horse :) (2) to doing such an analysis you need a clear specification of a SAVI mechanism which is outside the scope of this document. BTW, during my review of FCFS SAVI for the ID Write-Up document, text about residual threats was added inside the Security Considerations section. I will carefully check that the DHCP SAVI, SEND SAVI and the Mix Scenario documents take into account this issue before requesting AD/IESG review. Best regards. JMC. > >> 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. =A0I am >> certainly willing to talk with him about it. =A0But I would need to temp= er 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 h= is > 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 > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jeanmichel.combes@gmail.com Wed Jun 8 11:21: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 9CD6D11E80E3 for ; Wed, 8 Jun 2011 11:21:53 -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 C7gonW+KBCAW for ; Wed, 8 Jun 2011 11:21:51 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 17A8611E80E2 for ; Wed, 8 Jun 2011 11:21:51 -0700 (PDT) Received: by yib18 with SMTP id 18so492065yib.31 for ; Wed, 08 Jun 2011 11:21:46 -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:cc:content-type :content-transfer-encoding; bh=7VIjfQFVLLCyw9W9ozPBOgsvcQo/uNNkUwfRulmYz8s=; b=n/MNpFDXv4EOi3i1wq12mBrR6l5mpoGjvjFvACbzaU26Y4ngibyd4g5Jo+98pnFfKL czMKStmZ++3KqjVRrjEmYU1nT9Z1Bpp5nJrdcv7o3YtQwUPH4QBQ/4IT53FU8E6ZcncW M0ksjD2TySwICuGeGkdu4R0acPQYKrlhpplQs= 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 :cc:content-type:content-transfer-encoding; b=bFWFPs4xc9ngb1kgnRXaZQZIug74V9OpDJ746e4RBWL4YxsvGs7kH/W3cHRVEj6kBb O8ji4qepK7ZHiKRdBK4IF0ONP1jq8uy/FrZzGET+DuyCjVb8AdPOIq3HtnAroXJZderi qKhXYhK6KFBfTGOSB86pjbkzlgMyO0lNlldaI= MIME-Version: 1.0 Received: by 10.236.170.225 with SMTP id p61mr2638983yhl.231.1307557305374; Wed, 08 Jun 2011 11:21:45 -0700 (PDT) Received: by 10.147.125.3 with HTTP; Wed, 8 Jun 2011 11:21:45 -0700 (PDT) In-Reply-To: <4DE3A604.8080807@joelhalpern.com> References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> Date: Wed, 8 Jun 2011 20:21:45 +0200 Message-ID: From: Jean-Michel Combes To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Wed, 08 Jun 2011 18:21:53 -0000 Hi, 2011/5/30 Joel M. Halpern : [snip] > > 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. =A0This has bee= n > assumed to be significant by the working group. =A0The charter however ag= rees > with Stephen. =A0Before I can make a change of that scope, it needs WG > concurrence, as judged by the chair. (1) From a previous discussion on the ML (cf. http://www.ietf.org/mail-archive/web/savi/current/msg01573.html), it seems that logging is something expected by people wanting to deploy SAVI, what I must admit I understand when we know that most of the security tools have such a feature. (2) From the Threats document: "A second class of benefit is related to the traceability described above. When a security incident is detected, either within a site, or externally (and traced to the site) it can be critical to determine what the actual source of the incident was.". This is the only occurrence I saw about a trigger that should initiate a logging. (3) From BCP 38: "Network administrators should log information on packets which are dropped. This then provides a basis for monitoring any suspicious activity.". So, IMHO, the Threats document only provides the same type of advice. So, regarding the Threats documents, I must admit I don't see what is the i= ssue. > > It is the chair's task, as shepherd, to take these questions to the WG. = =A0I > will try to get the other comments dealt with. During the discussion on the ML about this topic there was no concern about logging references, so, from my point of view, there is already a WG consensus. Best regards. JMC. > > 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. =A0I am > certainly willing to talk with him about it. =A0But I would need to tempe= r 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 oth= er > issues. =A0I will contact Ralph this week. =A0It 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 softwa= re >>> 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 t= o >>> 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 b= e >>> 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 ar= e >>> 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 >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From stephen.farrell@cs.tcd.ie Wed Jun 15 05:24:28 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 56EBB11E80F8 for ; Wed, 15 Jun 2011 05:24:28 -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 jW5M04KV3pJc for ; Wed, 15 Jun 2011 05:24:27 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 41F7C11E80F0 for ; Wed, 15 Jun 2011 05:24:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 07765171C1E; Wed, 15 Jun 2011 13:24:03 +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=1308140642; bh=d6giFMSy7xEFZT wUNh0AFc9UiiOF8JHZXkoJudkwOvU=; b=xazsnY8PSRnvQKDrslAeVfgfgHnPxn DYGycqZwLyOkRVGBcrxZesLCtlmqUOmMayMTPGcA9Vuj//w2RLpI3hB/CByv9QKo 9ySNYgapSVhvH57qCcm9Z8QJp2ejWUgKc3Ttyb8F3bdRg1jGKQdubbWB1G54oq5g jWmb/2/SB2AsioAdAXW9EDscXp6F8hVRpPywtIzcAG5JoNS/doP0M6Z2nGj82WPN CblGmBmiKeCLNky2BnQrYArHDSKYGZ6mcQvgV/QZKHGn3zmLF9K8aKYkK7rVIojd cW+Rn5aoHaAEZ32iJRk+nqHRJGcJHTQsGzaFTBSd2UW5UJ++Fp/N+zHA== 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 QeJbY-YuJYP0; Wed, 15 Jun 2011 13:24:02 +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 C54B1171BFE; Wed, 15 Jun 2011 13:23:59 +0100 (IST) Message-ID: <4DF8A45F.8020702@cs.tcd.ie> Date: Wed, 15 Jun 2011 13:23:59 +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: Jean-Michel Combes References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> <4DE3BDE4.2040909@piuha.net> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List , draft-ietf-savi-threat-scope@tools.ietf.org 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: Wed, 15 Jun 2011 12:24:28 -0000 Hi Jean-Michel, On 08/06/11 18:28, Jean-Michel Combes wrote: > Hi, > > At first sorry for the delayed reply. > > Please, see my comments inline. > > 2011/5/30 Jari Arkko : >> 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 agree with Jari: > (1) IMHO, this would be like to put the cart before the horse :) > (2) to doing such an analysis you need a clear specification of a SAVI > mechanism which is outside the scope of this document. BTW, during my > review of FCFS SAVI for the ID Write-Up document, text about residual > threats was added inside the Security Considerations section. I will > carefully check that the DHCP SAVI, SEND SAVI and the Mix Scenario > documents take into account this issue before requesting AD/IESG > review. So my question then is where will I go to find a description of the residual threat for SAVI generally? Right now, it looks like there's going to be no place for that. The problem I see with that not being available is the following. Each SAVI mechanism (FCFS etc.) is going to catch certain forms of spoofing but inevitably leave others available and as you say those mechanism-specific residual threats will need to be documented in each SAVI spec. But I think there are dangers inherent in deploying a network with multiple SAVI mechanisms because of this - the issue being that an innocent party might be blamed for some action on the basis that a combination of SAVI mechanisms makes it "impossible" that the action actually involved spoofing. That kind of thing has happened in DRM-related cases so I think its important that the residual threat when all the various SAVI mechanisms are defined be properly documented somewhere. In addition I would assume that vendors are likely to implement more than one SAVI mechanism in some of their products, so customers for those products should also be interested in the residual threat for combinations of SAVI mechanisms. And I think that only the SAVI WG will have the expertise required to do that. Would it make sense to try get someone to write a document just on that towards the end of the process? (Assuming you could get a volunteer? I can try see if some security area type person would be willing to help as well if you like.) Cheers, Stephen. From jeanmichel.combes@gmail.com Wed Jun 15 07:11:18 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 1C3DE9E8016 for ; Wed, 15 Jun 2011 07:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.33 X-Spam-Level: X-Spam-Status: No, score=-103.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 vHZz8mrrE6nl for ; Wed, 15 Jun 2011 07:11:17 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF219E8014 for ; Wed, 15 Jun 2011 07:11:17 -0700 (PDT) Received: by gxk19 with SMTP id 19so368661gxk.31 for ; Wed, 15 Jun 2011 07:11:16 -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:cc:content-type :content-transfer-encoding; bh=Fhx2YE7NaExmeRm9lt4/FJxXVGlHzMPrr6aQriWbYw0=; b=rnihQ0kbLT/WII+pQQFyKios+wSNin9gn4M5HzdDAtm+diL0L8c8jyd4DOc4ZAgOHZ 0+soMmljFGRk7OqgzrPIqg5YxIX3Pw3OIVOF8Zgxr+Vz+4wN4itdq7tdyYOkiqV+PIWM U2D8LWbQLx1pgt+zjlbHOBHjtoIv1tcBoNhyA= 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 :cc:content-type:content-transfer-encoding; b=EQe7LvHXZILCmgkBfI44bpYX1H+gcz1DNYOVMwKuwj1ml6xMyI9eV07sYlmMig7xVl qOkxmY2Hwg7QdHabSkQCq0yHUMxoKpebApdudCsGxXgj4Lt6a6qPG+RoZEmeYV0oFaWQ N1RFPhHqMB9ixK0ZaQJSE96bQGFUmgHwkCbts= MIME-Version: 1.0 Received: by 10.146.109.6 with SMTP id h6mr665440yac.6.1308147076498; Wed, 15 Jun 2011 07:11:16 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Wed, 15 Jun 2011 07:11:16 -0700 (PDT) In-Reply-To: <4DF8A45F.8020702@cs.tcd.ie> References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> <4DE3BDE4.2040909@piuha.net> <4DF8A45F.8020702@cs.tcd.ie> Date: Wed, 15 Jun 2011 16:11:16 +0200 Message-ID: From: Jean-Michel Combes To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SAVI Mailing List , draft-ietf-savi-threat-scope@tools.ietf.org 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: Wed, 15 Jun 2011 14:11:18 -0000 Hi Stephen, I totally agree with you about the fact that deploying different SAVI solutions on a same architecture may have as consequences extra residual threats. That's why, from my point of view, the right place for such an analysis was the MIX SAVI document (http://tools.ietf.org/html/draft-ietf-savi-mix-00). Cheers. JMC. 2011/6/15 Stephen Farrell : > > Hi Jean-Michel, > > On 08/06/11 18:28, Jean-Michel Combes wrote: >> Hi, >> >> At first sorry for the delayed reply. >> >> Please, see my comments inline. >> >> 2011/5/30 Jari Arkko : >>> 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 scop= e 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 issue= s: >>>> >>>> 1) The issue of analysis of the effect of SAVI, and what threats remai= n >>>> after SAVI was requested by Stephen. =A0I pointed out that this is not= in >>>> scope for the document, and he said that he wanted it anyway. =A0I pun= ted to >>>> you and the chairs. =A0I believe it would take WG agreement, AD agreem= ent 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 too= ls >>> have been implemented in a network. I think we touched upon it in the c= all, >>> but I =A0can talk to Stephen about it. >> >> >> I agree with Jari: >> (1) IMHO, this would be like to put the cart before the horse :) >> (2) to doing such an analysis you need a clear specification of a SAVI >> mechanism which is outside the scope of this document. BTW, during my >> review of FCFS SAVI for the ID Write-Up document, text about residual >> threats was added inside the Security Considerations section. I will >> carefully check that the DHCP SAVI, SEND SAVI and the Mix Scenario >> documents take into account this issue before requesting AD/IESG >> review. > > So my question then is where will I go to find a description of > the residual threat for SAVI generally? Right now, it looks like > there's going to be no place for that. > > The problem I see with that not being available is the following. > > Each SAVI mechanism (FCFS etc.) is going to catch certain forms > of spoofing but inevitably leave others available and as you > say those mechanism-specific residual threats will need to be > documented in each SAVI spec. > > But I think there are dangers inherent in deploying a network > with multiple SAVI mechanisms because of this - the issue being > that an innocent party might be blamed for some action on the > basis that a combination of SAVI mechanisms makes it "impossible" > that the action actually involved spoofing. > > That kind of thing has happened in DRM-related cases so I > think its important that the residual threat when all the various > SAVI mechanisms are defined be properly documented somewhere. > > In addition I would assume that vendors are likely to implement > more than one SAVI mechanism in some of their products, so > customers for those products should also be interested in the > residual threat for combinations of SAVI mechanisms. > > And I think that only the SAVI WG will have the expertise > required to do that. > > Would it make sense to try get someone to write a document > just on that towards the end of the process? (Assuming you > could get a volunteer? I can try see if some security area > type person would be willing to help as well if you like.) > > Cheers, > Stephen. > From stephen.farrell@cs.tcd.ie Wed Jun 15 07:26: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 5967311E8137 for ; Wed, 15 Jun 2011 07:26:12 -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 xMvPJO5SjBI3 for ; Wed, 15 Jun 2011 07:26:11 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id E280411E8128 for ; Wed, 15 Jun 2011 07:26:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A270E171C1E; Wed, 15 Jun 2011 15:25:54 +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=1308147953; bh=SKF7OPGj66uw8V E/H1cC8R5jZMm0UId6YOFms6MqBxU=; b=7ICkbVOdZ66J4OaMnwtDnCQECcZk6r 6s8azfIF01z50E6yLNLCpYMTzdMX0XDye/LXkkN+cYb2vPlzCSh7gm1DyDqxEZBz 0c4pNpI8W4wb8gHXJQBPIGSFfP0gl3l85zpKbYxfI4IsB2kLdvbx+8w+GK8+5X0l u/hkHztYWZGvDdfmQAdQu7yiK1g/Zs1BVvmdQ+02w8Bmw5MKfytf60OA+U3/Nzj+ BkqoACldvzEoaq2/XQxLk01beQ3sLigRHNOOIQEDg3Mc96BtwViCijQ3GNawlgCg VtWj27WR4sAVZs4q3wBT88bG0jrk1wyye2369pgsThBZ2pdDIoQhbMEA== 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 0+I6Yu58Z8d2; Wed, 15 Jun 2011 15:25:53 +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 0787C171BFE; Wed, 15 Jun 2011 15:25:51 +0100 (IST) Message-ID: <4DF8C0EE.1050404@cs.tcd.ie> Date: Wed, 15 Jun 2011 15:25:50 +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: Jean-Michel Combes References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> <4DE3BDE4.2040909@piuha.net> <4DF8A45F.8020702@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 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: Wed, 15 Jun 2011 14:26:12 -0000 Hi Jean-Michel, On 15/06/11 15:11, Jean-Michel Combes wrote: > Hi Stephen, > > I totally agree with you about the fact that deploying different SAVI > solutions on a same architecture may have as consequences extra > residual threats. > That's why, from my point of view, the right place for such an > analysis was the MIX SAVI document > (http://tools.ietf.org/html/draft-ietf-savi-mix-00). So if you're saying that that document will eventually contain the residual threat analysis for all the others then I'm fine with that. Sorry for not spotting it, but I guess I can use the missing security considerations section in the -00 as my lame excuse:-) If that's the plan I'm happy to clear that part of the discuss. Cheers, S. > > Cheers. > > JMC. > > 2011/6/15 Stephen Farrell : >> >> Hi Jean-Michel, >> >> On 08/06/11 18:28, Jean-Michel Combes wrote: >>> Hi, >>> >>> At first sorry for the delayed reply. >>> >>> Please, see my comments inline. >>> >>> 2011/5/30 Jari Arkko : >>>> 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 agree with Jari: >>> (1) IMHO, this would be like to put the cart before the horse :) >>> (2) to doing such an analysis you need a clear specification of a SAVI >>> mechanism which is outside the scope of this document. BTW, during my >>> review of FCFS SAVI for the ID Write-Up document, text about residual >>> threats was added inside the Security Considerations section. I will >>> carefully check that the DHCP SAVI, SEND SAVI and the Mix Scenario >>> documents take into account this issue before requesting AD/IESG >>> review. >> >> So my question then is where will I go to find a description of >> the residual threat for SAVI generally? Right now, it looks like >> there's going to be no place for that. >> >> The problem I see with that not being available is the following. >> >> Each SAVI mechanism (FCFS etc.) is going to catch certain forms >> of spoofing but inevitably leave others available and as you >> say those mechanism-specific residual threats will need to be >> documented in each SAVI spec. >> >> But I think there are dangers inherent in deploying a network >> with multiple SAVI mechanisms because of this - the issue being >> that an innocent party might be blamed for some action on the >> basis that a combination of SAVI mechanisms makes it "impossible" >> that the action actually involved spoofing. >> >> That kind of thing has happened in DRM-related cases so I >> think its important that the residual threat when all the various >> SAVI mechanisms are defined be properly documented somewhere. >> >> In addition I would assume that vendors are likely to implement >> more than one SAVI mechanism in some of their products, so >> customers for those products should also be interested in the >> residual threat for combinations of SAVI mechanisms. >> >> And I think that only the SAVI WG will have the expertise >> required to do that. >> >> Would it make sense to try get someone to write a document >> just on that towards the end of the process? (Assuming you >> could get a volunteer? I can try see if some security area >> type person would be willing to help as well if you like.) >> >> Cheers, >> Stephen. >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jeanmichel.combes@gmail.com Wed Jun 15 07:46:25 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 AEA1921F8585 for ; Wed, 15 Jun 2011 07:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.384 X-Spam-Level: X-Spam-Status: No, score=-103.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 qUWd4iJSg9dl for ; Wed, 15 Jun 2011 07:46:25 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A72021F8584 for ; Wed, 15 Jun 2011 07:46:23 -0700 (PDT) Received: by yie30 with SMTP id 30so399746yie.31 for ; Wed, 15 Jun 2011 07:46:22 -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:cc:content-type :content-transfer-encoding; bh=563b64dweD8HSqdjNJ03PTHLcr33B/ZLJQXQBDK0BEY=; b=lDgpf2aWl1qIEWo/esE6TGJge4U66cCUsWaFZWcslec5lRVlu5vc9FPRYVthHF6NQy 4aYjdttJ5oHhL+9YslrshS/BCJEJi91kdgoGkvDbfhlavFSZ6+7v9Q+uAhQvA27grhRV yf3AW5SVfKkdyo8wXNHIBbfy/tF0tKbRXljbg= 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 :cc:content-type:content-transfer-encoding; b=CLkgq124GsBKZvHAfFkPBfg1fVzvR+1jii4KyuXA2BmFPyQVuOn1K5OtnP8sjObXUd fvnZa0CjfhCd4wBmovcfz2OP8hpMczR/DnaRuI5jYCVXeE4APzTgQPt4qyd6EPRBJV39 4zbeSv664y1dLCL9VOsJfG6OfW0gMR3aKeID8= MIME-Version: 1.0 Received: by 10.236.190.170 with SMTP id e30mr1062145yhn.226.1308149182185; Wed, 15 Jun 2011 07:46:22 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Wed, 15 Jun 2011 07:46:22 -0700 (PDT) In-Reply-To: <4DF8C0EE.1050404@cs.tcd.ie> References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> <4DE3BDE4.2040909@piuha.net> <4DF8A45F.8020702@cs.tcd.ie> <4DF8C0EE.1050404@cs.tcd.ie> Date: Wed, 15 Jun 2011 16:46:22 +0200 Message-ID: From: Jean-Michel Combes To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Wed, 15 Jun 2011 14:46:25 -0000 Hi again, 2011/6/15 Stephen Farrell : > > Hi Jean-Michel, > > On 15/06/11 15:11, Jean-Michel Combes wrote: >> Hi Stephen, >> >> I totally agree with you about the fact that deploying different SAVI >> solutions on a same architecture may have as consequences extra >> residual threats. >> That's why, from my point of view, the right place for such an >> analysis was the MIX SAVI document >> (http://tools.ietf.org/html/draft-ietf-savi-mix-00). > > So if you're saying that that document will eventually contain > the residual threat analysis for all the others then I'm fine > with that. Sorry for not spotting it, but I guess I can use > the missing security considerations section in the -00 as my > lame excuse:-) :) > > If that's the plan I'm happy to clear that part of the discuss. > Yes that's the plan and this is clearly identified in my TODO list for the review of this document. Cheers. JMC. > Cheers, > S. > > >> >> Cheers. >> >> JMC. >> >> 2011/6/15 Stephen Farrell : >>> >>> Hi Jean-Michel, >>> >>> On 08/06/11 18:28, Jean-Michel Combes wrote: >>>> Hi, >>>> >>>> At first sorry for the delayed reply. >>>> >>>> Please, see my comments inline. >>>> >>>> 2011/5/30 Jari Arkko : >>>>> 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 sc= ope 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 iss= ues: >>>>>> >>>>>> 1) The issue of analysis of the effect of SAVI, and what threats rem= ain >>>>>> after SAVI was requested by Stephen. =A0I pointed out that this is n= ot in >>>>>> scope for the document, and he said that he wanted it anyway. =A0I p= unted to >>>>>> you and the chairs. =A0I believe it would take WG agreement, AD agre= ement on >>>>>> scope change, and chair direction, before I can make that change. >>>>> >>>>> My opinion is that this document should NOT do that analysis or attem= pt to >>>>> find out precisely what residual threats are after some set of SAVI t= ools >>>>> have been implemented in a network. I think we touched upon it in the= call, >>>>> but I =A0can talk to Stephen about it. >>>> >>>> >>>> I agree with Jari: >>>> (1) IMHO, this would be like to put the cart before the horse :) >>>> (2) to doing such an analysis you need a clear specification of a SAVI >>>> mechanism which is outside the scope of this document. BTW, during my >>>> review of FCFS SAVI for the ID Write-Up document, text about residual >>>> threats was added inside the Security Considerations section. I will >>>> carefully check that the DHCP SAVI, SEND SAVI and the Mix Scenario >>>> documents take into account this issue before requesting AD/IESG >>>> review. >>> >>> So my question then is where will I go to find a description of >>> the residual threat for SAVI generally? Right now, it looks like >>> there's going to be no place for that. >>> >>> The problem I see with that not being available is the following. >>> >>> Each SAVI mechanism (FCFS etc.) is going to catch certain forms >>> of spoofing but inevitably leave others available and as you >>> say those mechanism-specific residual threats will need to be >>> documented in each SAVI spec. >>> >>> But I think there are dangers inherent in deploying a network >>> with multiple SAVI mechanisms because of this - the issue being >>> that an innocent party might be blamed for some action on the >>> basis that a combination of SAVI mechanisms makes it "impossible" >>> that the action actually involved spoofing. >>> >>> That kind of thing has happened in DRM-related cases so I >>> think its important that the residual threat when all the various >>> SAVI mechanisms are defined be properly documented somewhere. >>> >>> In addition I would assume that vendors are likely to implement >>> more than one SAVI mechanism in some of their products, so >>> customers for those products should also be interested in the >>> residual threat for combinations of SAVI mechanisms. >>> >>> And I think that only the SAVI WG will have the expertise >>> required to do that. >>> >>> Would it make sense to try get someone to write a document >>> just on that towards the end of the process? (Assuming you >>> could get a volunteer? I can try see if some security area >>> type person would be willing to help as well if you like.) >>> >>> Cheers, >>> Stephen. >>> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From stephen.farrell@cs.tcd.ie Wed Jun 15 08:35:28 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 5824911E8158 for ; Wed, 15 Jun 2011 08:35:28 -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 9MZQeAka432R for ; Wed, 15 Jun 2011 08:35:27 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF4611E814F for ; Wed, 15 Jun 2011 08:35:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 8D021171C20; Wed, 15 Jun 2011 16:34:56 +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=1308152096; bh=lLxD/YVBPoaCq6 fSsH8jC2Pb+VDEDt1e0/WfLmKfzrQ=; b=iLS5oJcnZYk3vHsWZfEOl7D13HRAaC zOHxKKG7+N2Y5NCh3huJM7YZx9o+6z8bfOzOh5fUARmn+f65O599OEu0Qg/KbyXR PxBUlpD2HQcRXtyGUTjCBuZAMxnDil2vJunj0Qu08l6uYi4w69fRe/HedvSWgXHG TCbqCo/JuZl0tEZOPaiWzdrN9ptVEwLqw1xvHlFX+FBTptGWRaiQg5qhf+OBFaFe rINcaFQI4ZsG711dUIqDuBbZwiZ+cnckO7hUa/BoQYzQUvtXfdZWbFnyuW3RIL/n WGn2zNBfo7PkrEURdB4snwQ/Yz58TAnCisC8X/X341fDZBC6V1x5ZbJw== 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 gnMtlecZkAuQ; Wed, 15 Jun 2011 16:34:56 +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 E6E14171BFE; Wed, 15 Jun 2011 16:34:53 +0100 (IST) Message-ID: <4DF8D11D.8000102@cs.tcd.ie> Date: Wed, 15 Jun 2011 16:34:53 +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: Jean-Michel Combes References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> <4DE3BDE4.2040909@piuha.net> <4DF8A45F.8020702@cs.tcd.ie> <4DF8C0EE.1050404@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List , draft-ietf-savi-threat-scope@tools.ietf.org 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: Wed, 15 Jun 2011 15:35:28 -0000 On 15/06/11 15:46, Jean-Michel Combes wrote: > Hi again, > > 2011/6/15 Stephen Farrell : >> >> Hi Jean-Michel, >> >> On 15/06/11 15:11, Jean-Michel Combes wrote: >>> Hi Stephen, >>> >>> I totally agree with you about the fact that deploying different SAVI >>> solutions on a same architecture may have as consequences extra >>> residual threats. >>> That's why, from my point of view, the right place for such an >>> analysis was the MIX SAVI document >>> (http://tools.ietf.org/html/draft-ietf-savi-mix-00). >> >> So if you're saying that that document will eventually contain >> the residual threat analysis for all the others then I'm fine >> with that. Sorry for not spotting it, but I guess I can use >> the missing security considerations section in the -00 as my >> lame excuse:-) > > :) > >> >> If that's the plan I'm happy to clear that part of the discuss. >> > > Yes that's the plan and this is clearly identified in my TODO list for > the review of this document. Grand. I've cleared the two relevant discuss points (2 & 17). I copied that text down to the end of the comments to help keep track as we kill off the other discuss and comment points. Thanks, S. > > Cheers. > > JMC. > >> Cheers, >> S. >> >> >>> >>> Cheers. >>> >>> JMC. >>> >>> 2011/6/15 Stephen Farrell : >>>> >>>> Hi Jean-Michel, >>>> >>>> On 08/06/11 18:28, Jean-Michel Combes wrote: >>>>> Hi, >>>>> >>>>> At first sorry for the delayed reply. >>>>> >>>>> Please, see my comments inline. >>>>> >>>>> 2011/5/30 Jari Arkko : >>>>>> 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 agree with Jari: >>>>> (1) IMHO, this would be like to put the cart before the horse :) >>>>> (2) to doing such an analysis you need a clear specification of a SAVI >>>>> mechanism which is outside the scope of this document. BTW, during my >>>>> review of FCFS SAVI for the ID Write-Up document, text about residual >>>>> threats was added inside the Security Considerations section. I will >>>>> carefully check that the DHCP SAVI, SEND SAVI and the Mix Scenario >>>>> documents take into account this issue before requesting AD/IESG >>>>> review. >>>> >>>> So my question then is where will I go to find a description of >>>> the residual threat for SAVI generally? Right now, it looks like >>>> there's going to be no place for that. >>>> >>>> The problem I see with that not being available is the following. >>>> >>>> Each SAVI mechanism (FCFS etc.) is going to catch certain forms >>>> of spoofing but inevitably leave others available and as you >>>> say those mechanism-specific residual threats will need to be >>>> documented in each SAVI spec. >>>> >>>> But I think there are dangers inherent in deploying a network >>>> with multiple SAVI mechanisms because of this - the issue being >>>> that an innocent party might be blamed for some action on the >>>> basis that a combination of SAVI mechanisms makes it "impossible" >>>> that the action actually involved spoofing. >>>> >>>> That kind of thing has happened in DRM-related cases so I >>>> think its important that the residual threat when all the various >>>> SAVI mechanisms are defined be properly documented somewhere. >>>> >>>> In addition I would assume that vendors are likely to implement >>>> more than one SAVI mechanism in some of their products, so >>>> customers for those products should also be interested in the >>>> residual threat for combinations of SAVI mechanisms. >>>> >>>> And I think that only the SAVI WG will have the expertise >>>> required to do that. >>>> >>>> Would it make sense to try get someone to write a document >>>> just on that towards the end of the process? (Assuming you >>>> could get a volunteer? I can try see if some security area >>>> type person would be willing to help as well if you like.) >>>> >>>> Cheers, >>>> Stephen. >>>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jeanmichel.combes@gmail.com Thu Jun 16 13:49:56 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 31ECC11E8146 for ; Thu, 16 Jun 2011 13:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.446 X-Spam-Level: X-Spam-Status: No, score=-103.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 8v-t+XAOSrpD for ; Thu, 16 Jun 2011 13:49:54 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 745AC11E80E5 for ; Thu, 16 Jun 2011 13:49:54 -0700 (PDT) Received: by yxt33 with SMTP id 33so1590587yxt.31 for ; Thu, 16 Jun 2011 13:49:54 -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:cc:content-type; bh=1KwuJ1+WGwBHrHuosI/Mj2LS6vhzvsHdx072zkei9dY=; b=XEkJ7fyfjSQyK28v+hRiSJU5T+WoXMQ2ftJd4Jf10GliYhR9LSJExCOK9jgwDd93/I AXK7jJuH/I24j7GVvb3nzJsfhgbj9lrNFHkZLvd5TSJb5TvLzymASLBchgCjKfmLChJY OFVbGtxvv2oN/VbrSCFw61+SzT2rM5ebUe3Fk= 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 :cc:content-type; b=etwRIj1EV8G2LI7pKdbNA2vPmuowfPIFU2Jj05/I8uPiAasYITcrW6zq/WBTfnOh79 1uPORGtQ0QUUxhPAoqWMiFDYyIbJ6prsaWw1lvQ3tC0v+qU2Na46aYfBzdOvhExsrZ36 61Q1iRTbIdXXB93gc0jvANR0BYj+IJ0LHOksM= MIME-Version: 1.0 Received: by 10.236.77.165 with SMTP id d25mr2008767yhe.25.1308257393748; Thu, 16 Jun 2011 13:49:53 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Thu, 16 Jun 2011 13:49:53 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Jun 2011 22:49:53 +0200 Message-ID: From: Jean-Michel Combes To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: int-ads@tools.ietf.org, Christian Vogt Subject: Re: [savi] Call for WG items for a potential rechartering 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, 16 Jun 2011 20:49:56 -0000 Folks, just a friendly reminder about the deadline. Best regards. JMC. 2011/6/6 Jean-Michel Combes : > Folks, > > As promised during the last SAVI meeting in Prague, to prepare the > next IETF meeting, I would like to know whether WG members believe > there are still open issues the WG needs to work on or not. > > If so, please, reply to this email, providing a clear description of > the item and your contribution (i.e. Editor, Co-Author, Reviewer). For > each proposed item, at least three volunteers ready to review the > future document are requested. > > If you believe the WG has finished the work and can be closed, don't > hesitate to tell it too. > > The deadline to reply is 2011-06-20. > > Thanks in advance. > > Best regards. > > JMC. > From stephen.farrell@cs.tcd.ie Thu Jun 16 14:28:49 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 B7BF411E8323 for ; Thu, 16 Jun 2011 14:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.601 X-Spam-Level: X-Spam-Status: No, score=-105.601 tagged_above=-999 required=5 tests=[AWL=0.998, 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 DjcpBPu3AyQv for ; Thu, 16 Jun 2011 14:28:47 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id A597911E8319 for ; Thu, 16 Jun 2011 14:28:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 62D5D171C20; Thu, 16 Jun 2011 22:28:42 +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=1308259721; bh=ZHkvgLQP/iWOxa TBOG2VXyW2LBBGgtHklEkd55FUYd4=; b=MaaHaJh0JGBK7URv6OHJ60d2diN0YA SL7Rzymrfp38GnSGMNKW4BMgentlsTA84AblZHPVIVN5Js7h0+Nf5ZMLixWeUYYT xcin8g+Sv7eCfAgDKmmr0RVqKzOMxyNFbQCfIqzF13umT8ylf6DMOIvYjP6DbiJF +kLv1OyUY3ujmFzlbh4c3u2AjMLb0IU0Vn9aTiaQDJ3Djf1hxPRyEHRThoazsXr9 FxoisQDkLLW+I/fkq90bdZe7tJkhAAFax0cvNjnhXQT5+iAVGtwZCwc5seSuivYO KhQAmWv8ff1x+fI3RULyrA4FyK6g9vIBNRiQlX31eZMVjH2Wj8itHdgw== 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 9ty7M9E8wRWM; Thu, 16 Jun 2011 22:28:41 +0100 (IST) Received: from [10.87.48.10] (unknown [86.42.183.124]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A067E171C19; Thu, 16 Jun 2011 22:28:38 +0100 (IST) Message-ID: <4DFA7585.4060406@cs.tcd.ie> Date: Thu, 16 Jun 2011 22:28:37 +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: Jean-Michel Combes References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List , draft-ietf-savi-threat-scope@tools.ietf.org 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: Thu, 16 Jun 2011 21:28:51 -0000 Hi Jean-Michel, Let's see if we can figure the other tricky bit of my discuss as quickly as the other! Although I raised the same issue in my discuss on FCFS, I think dealing with it on this document is better since I reckon the same thing is likely to occur with all SAVI docs, so if we can figure it out independent of FCFS that should be better. So this is about logging. To be clear - I have no problem if SAVI mechanisms log some information when a spoofing event of some sort has been prevented/detected, my problem lies in SAVI logging binding anchor information for the 90-something percent of cases where there is no spoofing at all. I do not think that such ubiquitous logging is in scope of the WG charter which states that SAVI is about preventing spoofing and that "Tracking other protocols is not within the scope of the WG." Separately, there is rfc 2804. As far as I know that is the most relevant IETF consensus position here. And that was arrived at after an extended and wide ranging debate (one of the IETF's finer moments IMO, but that's beside the point). Of course that wasn't precisely addressing the same issue, but I think its close enough. Given the various combinations of privacy and data retention laws in various jurisdictions, and the fact that ubiquitous logging would put SAVI into the ballpark of wiretapping functionality, it seems to me that the same conclusion should apply when considering whether SAVI mechanisms ought to log information for every binding anchor. I'm not sure whether or not WG participants considered this in relation to the logging issue or not. I would also suspect that achieving a freshly minted IETF consensus on this particular point might be as time consuming as the raven process. (Might not be a bad thing though to get an IETF consensus on that if we really needed to do it.) So I think that given that the charter and rfc 2804 have IETF consensus that would trump even a quite strong WG consensus on this topic. Hence my discuss. (As an aside, if some spoofing can still occur for any combination of SAVI mechanisms such ubiquitous logging makes me even more nervous - that'd be like a wiretap technology that sometimes records the wrong call or something.) A few more minor points below. On 08/06/11 19:21, Jean-Michel Combes wrote: > Hi, > > 2011/5/30 Joel M. Halpern : > > [snip] > >> >> 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. > > (1) From a previous discussion on the ML (cf. > http://www.ietf.org/mail-archive/web/savi/current/msg01573.html), it > seems that logging is something expected by people wanting to deploy > SAVI, what I must admit I understand when we know that most of the > security tools have such a feature. So that's a thread with Joel, you and another person contributing. Joel now seems to agree that logging like this is problematic given the WG charter and you're calling the consensus, so I guess that's not quite an overwhelmingly strong WG consensus:-) No one did object granted, and there may be a lot of silent agreement, but I'm just going on the archive. > (2) From the Threats document: "A second class of benefit is related > to the traceability described above. When a security incident is > detected, either within a site, or externally (and traced to the site) > it can be critical to determine what the actual source of the incident > was.". This is the only occurrence I saw about a trigger that should > initiate a logging. Traceability implies a lot to me. It has serious privacy consequences. See above. > (3) From BCP 38: "Network administrators should log information on > packets which are dropped. This then provides a basis for monitoring > any suspicious activity.". So, IMHO, the Threats document only > provides the same type of advice. If SAVI only mandates logging related to spoofs then that'd be ok and consistent with BCP38. Are you arguing that logging everything is what BCP 38 calls for? > > So, regarding the Threats documents, I must admit I don't see what is the issue. > >> >> 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. > > During the discussion on the ML about this topic there was no concern > about logging references, so, from my point of view, there is already > a WG consensus. But not, I think, IETF consensus. Cheers, S. > > Best regards. > > JMC. > >> >> 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 >>> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From junbi@tsinghua.edu.cn Thu Jun 16 20:08:38 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 C6C5921F8519 for ; Thu, 16 Jun 2011 20:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.103 X-Spam-Level: X-Spam-Status: No, score=-101.103 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_DSN=1.495, STOX_REPLY_TYPE=0.001, 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 E7Y64CZHZP2K for ; Thu, 16 Jun 2011 20:08:38 -0700 (PDT) Received: from smtp.tsinghua.edu.cn (smtp.tsinghua.edu.cn [166.111.8.81]) by ietfa.amsl.com (Postfix) with ESMTP id DB2DB21F8511 for ; Thu, 16 Jun 2011 20:08:36 -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 1QXPQ4-0000tA-W0; Fri, 17 Jun 2011 11:08:29 +0800 Message-ID: From: "Jun Bi" To: "Jean-Michel Combes" , "SAVI Mailing List" References: In-Reply-To: Date: Fri, 17 Jun 2011 11:08:24 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original 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 Cc: int-ads@tools.ietf.org, Christian Vogt Subject: Re: [savi] Call for WG items for a potential rechartering 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, 17 Jun 2011 03:08:38 -0000 Dear WG chairs, Here are some suggestions. I think after the solutions are finialized, then the SAVI mib is necessary, here is an example http://datatracker.ietf.org/doc/draft-an-savi-mib/ Aslo, after the solution senario for fixed LAN is finalized, then the senario of WLAN needs to be consdiered, espeially for the host moving in centrailized WLAN (CAPWEB case) and distribued WLAN. Here is an example http://datatracker.ietf.org/doc/draft-bi-savi-wlan/ Based on CERENT's collabration with telecom carrieres such as China telecom, the telecom has some requirements to deploy savi at BRAS equipment, to bind IPv6 source address with PPP session, then at that case, maybe SAVI WG needs to study the senarios and requirements, then proivide guidelines or solution enhancement. Moveover, to extend SAVI to intra-AS and inter-AS senario may aslo needs to be studied, starting at how the current solution resolves the problems, is there any new idea can enhance it. Thank you very much! Jun Bi -----原始邮件----- From: Jean-Michel Combes Sent: Friday, June 17, 2011 4:49 AM To: SAVI Mailing List Cc: int-ads@tools.ietf.org ; Christian Vogt Subject: Re: [savi] Call for WG items for a potential rechartering Folks, just a friendly reminder about the deadline. Best regards. JMC. 2011/6/6 Jean-Michel Combes : > Folks, > > As promised during the last SAVI meeting in Prague, to prepare the > next IETF meeting, I would like to know whether WG members believe > there are still open issues the WG needs to work on or not. > > If so, please, reply to this email, providing a clear description of > the item and your contribution (i.e. Editor, Co-Author, Reviewer). For > each proposed item, at least three volunteers ready to review the > future document are requested. > > If you believe the WG has finished the work and can be closed, don't > hesitate to tell it too. > > The deadline to reply is 2011-06-20. > > Thanks in advance. > > Best regards. > > JMC. > _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From jeanmichel.combes@gmail.com Mon Jun 20 08:26: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 DE03D9E800D for ; Mon, 20 Jun 2011 08:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.461 X-Spam-Level: X-Spam-Status: No, score=-103.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 0mr5GruFCZmL for ; Mon, 20 Jun 2011 08:26:07 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA4AB9E802D for ; Mon, 20 Jun 2011 08:25:51 -0700 (PDT) Received: by gya6 with SMTP id 6so1120093gya.31 for ; Mon, 20 Jun 2011 08:25:51 -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:cc:content-type :content-transfer-encoding; bh=i6LUWjqf2tJ3MSYAfw3XT8P4+xCyuG4d7MCW/SphpZA=; b=VpB6JJR2rMC6nTbCVj1sw/BvV4A949aDVXLXHm3H1FZMg05huw8jkhfEDEw+oLfT4d zPuBWqAxupGWwZVbRZdxl2URRM8E/Ydl8LFCTytflfmAbzAyyYlAP6vCZMMPb9Tox7oX sC2UlmNdzfvBQfdP+qZk7rVe6bQ+Rnscs4s9w= 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 :cc:content-type:content-transfer-encoding; b=ejwYeUYpXZpFyjGkubI69KwwALVsa+96QeMfFGsk3dhbxjuOzz7IDJij2LmqElhrI7 nuSTqXzRrr39DvaTLzwcAlZkJoIo4KobPT2C3pxFXMh/PW0B4p/2195PvMGrdDYjPZq0 BFDKNMkVJGuFXPzrBkb4UBgf5yiTcIEWxrtUo= MIME-Version: 1.0 Received: by 10.151.92.2 with SMTP id u2mr6219272ybl.209.1308583551152; Mon, 20 Jun 2011 08:25:51 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Mon, 20 Jun 2011 08:25:50 -0700 (PDT) In-Reply-To: <4DFA7585.4060406@cs.tcd.ie> References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> <4DFA7585.4060406@cs.tcd.ie> Date: Mon, 20 Jun 2011 17:25:50 +0200 Message-ID: From: Jean-Michel Combes To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SAVI Mailing List , draft-ietf-savi-threat-scope@tools.ietf.org 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, 20 Jun 2011 15:26:10 -0000 Hi Stephen, 2011/6/16 Stephen Farrell : > > Hi Jean-Michel, > > Let's see if we can figure the other tricky bit of my discuss > as quickly as the other! OK. > > Although I raised the same issue in my discuss on FCFS, I > think dealing with it on this document is better since I reckon > the same thing is likely to occur with all SAVI docs, so if > we can figure it out independent of FCFS that should be better. Agree. > > So this is about logging. To be clear - I have no problem if > SAVI mechanisms log some information when a spoofing event of > some sort has been prevented/detected, my problem lies in > SAVI logging binding anchor information for the 90-something > percent of cases where there is no spoofing at all. > > I do not think that such ubiquitous logging is in scope > of the WG charter which states that SAVI is about preventing > spoofing and that "Tracking other protocols is not within > the scope of the WG." > > Separately, there is rfc 2804. As far as I know that is the > most relevant IETF consensus position here. And that was > arrived at after an extended and wide ranging debate (one > of the IETF's finer moments IMO, but that's beside the > point). > > Of course that wasn't precisely addressing the same issue, > but I think its close enough. Given the various combinations > of privacy and data retention laws in various jurisdictions, > and the fact that ubiquitous logging would put SAVI into > the ballpark of wiretapping functionality, it seems to me > that the same conclusion should apply when considering whether > SAVI mechanisms ought to log information for every binding > anchor. > > I'm not sure whether or not WG participants considered this > in relation to the logging issue or not. > > I would also suspect that achieving a freshly minted IETF > consensus on this particular point might be as time > consuming as the raven process. (Might not be a bad thing > though to get an IETF consensus on that if we really > needed to do it.) > > So I think that given that the charter and rfc 2804 have > IETF consensus that would trump even a quite strong WG > consensus on this topic. Hence my discuss. > What can be done in the different SAVI documents, is to restrict logging only when an incident has been detected (i.e. use of an IP address not allowed on a binding anchor). Would it be fine for you? > (As an aside, if some spoofing can still occur for any > combination of SAVI mechanisms such ubiquitous logging makes > me even more nervous - that'd be like a wiretap technology > that sometimes records the wrong call or something.) > > A few more minor points below. > > On 08/06/11 19:21, Jean-Michel Combes wrote: >> Hi, >> >> 2011/5/30 Joel M. Halpern : >> >> [snip] >> >>> >>> 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 t= o be >>> used, and its utility is strengthened by the use of SAVI. =A0This has b= een >>> assumed to be significant by the working group. =A0The charter however = agrees >>> with Stephen. =A0Before I can make a change of that scope, it needs WG >>> concurrence, as judged by the chair. >> >> (1) From a previous discussion on the ML (cf. >> http://www.ietf.org/mail-archive/web/savi/current/msg01573.html), it >> seems that logging is something expected by people wanting to deploy >> SAVI, what I must admit I understand when we know that most of the >> security tools have such a feature. > > So that's a thread with Joel, you and another person contributing. > Joel now seems to agree that logging like this is problematic > given the WG charter and you're calling the consensus, so I guess > that's not quite an overwhelmingly strong WG consensus:-) > No one did object granted, and there may be a lot of silent > agreement, but I'm just going on the archive. > Yes, this was a silent agreement. >> (2) From the Threats document: "A second class of benefit is related >> to the traceability described above. When a security incident is >> detected, either within a site, or externally (and traced to the site) >> it can be critical to determine what the actual source of the incident >> was.". This is the only occurrence I saw about a trigger that should >> initiate a logging. > > Traceability implies a lot to me. It has serious privacy consequences. > See above. > >> (3) From BCP 38: "Network administrators should log information on >> packets which are dropped. This then provides a basis for monitoring >> any suspicious activity.". So, IMHO, the Threats document only >> provides the same type of advice. > > If SAVI only mandates logging related to spoofs then that'd be > ok and consistent with BCP38. Are you arguing that logging everything > is what BCP 38 calls for? > No no: from my point of view, BCP 38 only recommends to log when incidents occur. Cheers. JMC. >> >> So, regarding the Threats documents, I must admit I don't see what is th= e issue. >> >>> >>> It is the chair's task, as shepherd, to take these questions to the WG.= =A0I >>> will try to get the other comments dealt with. >> >> During the discussion on the ML about this topic there was no concern >> about logging references, so, from my point of view, there is already >> a WG consensus. > > But not, I think, IETF consensus. > > Cheers, > S. > >> >> Best regards. >> >> JMC. >> >>> >>> 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. =A0I am >>> certainly willing to talk with him about it. =A0But I would need to tem= per 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 o= ther >>> issues. =A0I will contact Ralph this week. =A0It was only on Sunday tha= t I >>> reached an understanding of what Stephen was asking for in point 2 abov= e. >>> >>> 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 ar= e >>>> 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 ensur= e >>>> 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. (Tha= t >>>> 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 bridg= e >>>>> or layer >>>>> 2 switch) access control standard that controls the joining of device= s >>>>> to a >>>>> layer 2 bridged network. The term 'tools' is not in place and there i= s >>>>> 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 soft= ware >>>>> 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 t= o >>>>> 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 abou= t >>>>> non-blind >>>>> attacks just as much. The example given of a host on-link with router= s >>>>> 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 sentenc= e >>>>> 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 th= at >>>>> 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 th= e >>>>> 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 base= d >>>>> 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 SAV= I >>>>> versus "ad hoc" SAVI. In the case of DHCP based SAVI, the switch can >>>>> have authoritative information about the address/port binding, becaus= e >>>>> 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 trackin= g >>>>> 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 >>>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > From stephen.farrell@cs.tcd.ie Mon Jun 20 09:01: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 C49919E8035 for ; Mon, 20 Jun 2011 09:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.109 X-Spam-Level: X-Spam-Status: No, score=-106.109 tagged_above=-999 required=5 tests=[AWL=0.490, 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 2a0EFW3Ye3Dl for ; Mon, 20 Jun 2011 09:01:17 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 246689E800D for ; Mon, 20 Jun 2011 09:01:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 433EA171C18; Mon, 20 Jun 2011 17:01:04 +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=1308585662; bh=LL/iKb7wl0Kutm DDhk5q30qC2iK7uvt9E6LGNlivdmU=; b=KJah4OLgv7tIvhgUf2XlS6yKuU32S7 ZbtUfO+9/vEKV1SrE9YobsuhQhjik7WPU7CzyPfQ5PtEYIbrf0XhaPm01pogxVxQ MwzPARH3f1hq5VLPOn4lq4/bi3oYnA62NfsZTH78M4b329UVzL6efxWo8iGK9AjV 9GlQH/rt93xnTOzaaNtc7eVypir319oFaD013Wj+WtWE4G0l7bKYzPFY+0urioxD U2T8bc9o+lgChtI3YgKAjLB9aAmeHOEcOC3qdDM3nQHyDZifUfEly8YXagdOD2bS C6KEedACzCE7inp4dzLViQ2EfguA7M2oDoraxic2ehh6uZb9mUy14I6Q== 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 K8tWzxW6eFOv; Mon, 20 Jun 2011 17:01:02 +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 B0F83171C17; Mon, 20 Jun 2011 17:01:00 +0100 (IST) Message-ID: <4DFF6EBC.9080406@cs.tcd.ie> Date: Mon, 20 Jun 2011 17:01:00 +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: Jean-Michel Combes References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> <4DFA7585.4060406@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 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, 20 Jun 2011 16:01:20 -0000 On 20/06/11 16:25, Jean-Michel Combes wrote: > Hi Stephen, > > 2011/6/16 Stephen Farrell : >> >> Hi Jean-Michel, >> >> Let's see if we can figure the other tricky bit of my discuss >> as quickly as the other! > > OK. > >> >> Although I raised the same issue in my discuss on FCFS, I >> think dealing with it on this document is better since I reckon >> the same thing is likely to occur with all SAVI docs, so if >> we can figure it out independent of FCFS that should be better. > > Agree. > >> >> So this is about logging. To be clear - I have no problem if >> SAVI mechanisms log some information when a spoofing event of >> some sort has been prevented/detected, my problem lies in >> SAVI logging binding anchor information for the 90-something >> percent of cases where there is no spoofing at all. >> >> I do not think that such ubiquitous logging is in scope >> of the WG charter which states that SAVI is about preventing >> spoofing and that "Tracking other protocols is not within >> the scope of the WG." >> >> Separately, there is rfc 2804. As far as I know that is the >> most relevant IETF consensus position here. And that was >> arrived at after an extended and wide ranging debate (one >> of the IETF's finer moments IMO, but that's beside the >> point). >> >> Of course that wasn't precisely addressing the same issue, >> but I think its close enough. Given the various combinations >> of privacy and data retention laws in various jurisdictions, >> and the fact that ubiquitous logging would put SAVI into >> the ballpark of wiretapping functionality, it seems to me >> that the same conclusion should apply when considering whether >> SAVI mechanisms ought to log information for every binding >> anchor. >> >> I'm not sure whether or not WG participants considered this >> in relation to the logging issue or not. >> >> I would also suspect that achieving a freshly minted IETF >> consensus on this particular point might be as time >> consuming as the raven process. (Might not be a bad thing >> though to get an IETF consensus on that if we really >> needed to do it.) >> >> So I think that given that the charter and rfc 2804 have >> IETF consensus that would trump even a quite strong WG >> consensus on this topic. Hence my discuss. >> > > What can be done in the different SAVI documents, is to restrict > logging only when an incident has been detected (i.e. use of an IP > address not allowed on a binding anchor). > > Would it be fine for you? Only logging when an incident has been detected sounds perfect to me. Thanks for considering this, Regards, Stephen. > >> (As an aside, if some spoofing can still occur for any >> combination of SAVI mechanisms such ubiquitous logging makes >> me even more nervous - that'd be like a wiretap technology >> that sometimes records the wrong call or something.) >> >> A few more minor points below. >> >> On 08/06/11 19:21, Jean-Michel Combes wrote: >>> Hi, >>> >>> 2011/5/30 Joel M. Halpern : >>> >>> [snip] >>> >>>> >>>> 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. >>> >>> (1) From a previous discussion on the ML (cf. >>> http://www.ietf.org/mail-archive/web/savi/current/msg01573.html), it >>> seems that logging is something expected by people wanting to deploy >>> SAVI, what I must admit I understand when we know that most of the >>> security tools have such a feature. >> >> So that's a thread with Joel, you and another person contributing. >> Joel now seems to agree that logging like this is problematic >> given the WG charter and you're calling the consensus, so I guess >> that's not quite an overwhelmingly strong WG consensus:-) >> No one did object granted, and there may be a lot of silent >> agreement, but I'm just going on the archive. >> > > Yes, this was a silent agreement. > >>> (2) From the Threats document: "A second class of benefit is related >>> to the traceability described above. When a security incident is >>> detected, either within a site, or externally (and traced to the site) >>> it can be critical to determine what the actual source of the incident >>> was.". This is the only occurrence I saw about a trigger that should >>> initiate a logging. >> >> Traceability implies a lot to me. It has serious privacy consequences. >> See above. >> >>> (3) From BCP 38: "Network administrators should log information on >>> packets which are dropped. This then provides a basis for monitoring >>> any suspicious activity.". So, IMHO, the Threats document only >>> provides the same type of advice. >> >> If SAVI only mandates logging related to spoofs then that'd be >> ok and consistent with BCP38. Are you arguing that logging everything >> is what BCP 38 calls for? >> > > No no: from my point of view, BCP 38 only recommends to log when > incidents occur. > > Cheers. > > JMC. > >>> >>> So, regarding the Threats documents, I must admit I don't see what is the issue. >>> >>>> >>>> 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. >>> >>> During the discussion on the ML about this topic there was no concern >>> about logging references, so, from my point of view, there is already >>> a WG consensus. >> >> But not, I think, IETF consensus. >> >> Cheers, >> S. >> >>> >>> Best regards. >>> >>> JMC. >>> >>>> >>>> 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 >>>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jeanmichel.combes@gmail.com Mon Jun 20 10:56:00 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 D9EA111E808E for ; Mon, 20 Jun 2011 10:56:00 -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 3VRmCFq8sZK9 for ; Mon, 20 Jun 2011 10:56:00 -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 22FCF11E808A for ; Mon, 20 Jun 2011 10:56:00 -0700 (PDT) Received: by gwb20 with SMTP id 20so919529gwb.31 for ; Mon, 20 Jun 2011 10:55:59 -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:cc:content-type; bh=LgOy8X6Jyc3Mj2pNtwe8tnAabx/yd6g9KsShDvsb8vY=; b=rBvSqYH3/dEfZqOIO7UGghtOpaLmzao31N8426BBA+l0WdeTuYyOPm7Ry4QIHrY2tQ xVpjuM9IboV3+ZTguhP5CZKDsMQMWAP+7qstOcGdc6p5qPmPxyziHXysJdVzY9ocp+Jm Dprvi4gRHzeFaASXqKZB6AhpOa5QCmSfiL14o= 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 :cc:content-type; b=aPLujI9Ucd35UdhV5fwW2d7xNgvWviyP/6kRyQWZ/6V7QtxQ6Yl/lWRWSLR7sPBmQW SCn07uJ54pkjnGMXibkhuO50xTOp+buQOOVElE/Mspii+R6YF/2oYx2Zy8RzhFm36LBN KeLF9DwuodCtsnEVad2bfvRyUqd9E0/ki4iKE= MIME-Version: 1.0 Received: by 10.150.62.19 with SMTP id k19mr6391459yba.38.1308592559611; Mon, 20 Jun 2011 10:55:59 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Mon, 20 Jun 2011 10:55:59 -0700 (PDT) In-Reply-To: <4DFF6EBC.9080406@cs.tcd.ie> References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> <4DFA7585.4060406@cs.tcd.ie> <4DFF6EBC.9080406@cs.tcd.ie> Date: Mon, 20 Jun 2011 19:55:59 +0200 Message-ID: From: Jean-Michel Combes To: Stephen Farrell Content-Type: text/plain; charset=ISO-8859-1 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, 20 Jun 2011 17:56:01 -0000 Stephen, fine! I will check carefully this point during my future reviews. Now, coming back on the Threats document, do you think some text is not compliant with your requirement? Thanks in advance. Best regards. JMC. 2011/6/20 Stephen Farrell : > > > On 20/06/11 16:25, Jean-Michel Combes wrote: >> Hi Stephen, >> [snip] >>> >>> So I think that given that the charter and rfc 2804 have >>> IETF consensus that would trump even a quite strong WG >>> consensus on this topic. Hence my discuss. >>> >> >> What can be done in the different SAVI documents, is to restrict >> logging only when an incident has been detected (i.e. use of an IP >> address not allowed on a binding anchor). >> >> Would it be fine for you? > > Only logging when an incident has been detected sounds > perfect to me. > > Thanks for considering this, > Regards, > Stephen. > > [snip] From stephen.farrell@cs.tcd.ie Mon Jun 20 11:12:44 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 4354D11E819E for ; Mon, 20 Jun 2011 11:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.154 X-Spam-Level: X-Spam-Status: No, score=-106.154 tagged_above=-999 required=5 tests=[AWL=0.445, 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 g6SdknFARJsq for ; Mon, 20 Jun 2011 11:12:42 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9223011E81B7 for ; Mon, 20 Jun 2011 11:12:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 24C8A171C19; Mon, 20 Jun 2011 19:12:20 +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=1308593539; bh=EPrn2ImEMTH5KO 4Y80UTrOayraG4tIhntuGik5RC0h4=; b=nv2tdsmqgHVaBBfgy4Kc1BOjjUHUso wBmNgflOF2tvUbGTnuPxj4qElQQJcEoWp5DDfJGoS3R1vw6o+UES8URaPwEeqiZm iKVT+AuAU92v7ARB2hoVAGWOSRTkd0/e/0ks/8F2m82feV6JXZYvz9/oL7mtzNGZ 92J+gxEt5anJZh1qYjzvkFlpPy05Ea77VErXc0/ykcrVUXS8vrnlzw52Ir3HwQdg Rj8yMw1rX8993cDv4h+QMXN6QFeMBc2O+TeOW0vy0GL9y6OL/9sCMm8sCFrp5QX4 s+D/kWJBp37eM1Ar+1DH7DJsP4VoWIYjFjyxQzt52AqiarQMrCM+59zA== 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 kyKSk3BG3qnY; Mon, 20 Jun 2011 19:12:19 +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 72D11171C18; Mon, 20 Jun 2011 19:12:18 +0100 (IST) Message-ID: <4DFF8D82.5080001@cs.tcd.ie> Date: Mon, 20 Jun 2011 19:12:18 +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: Jean-Michel Combes References: <20110526184749.21820.68101.idtracker@ietfa.amsl.com> <4DE34147.8070103@piuha.net> <4DE3A604.8080807@joelhalpern.com> <4DFA7585.4060406@cs.tcd.ie> <4DFF6EBC.9080406@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List , draft-ietf-savi-threat-scope@tools.ietf.org 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, 20 Jun 2011 18:12:44 -0000 Hiya, On 20/06/11 18:55, Jean-Michel Combes wrote: > Stephen, fine! I will check carefully this point during my future reviews. Lovely. > Now, coming back on the Threats document, do you think some text is > not compliant with your requirement? I think my discuss points 3, 18 and 21 for this document are the relevant ones. With our current understanding they should be easy fixes. Cheers, S. > > Thanks in advance. > > Best regards. > > JMC. > > 2011/6/20 Stephen Farrell : >> >> >> On 20/06/11 16:25, Jean-Michel Combes wrote: >>> Hi Stephen, >>> > > [snip] > >>>> >>>> So I think that given that the charter and rfc 2804 have >>>> IETF consensus that would trump even a quite strong WG >>>> consensus on this topic. Hence my discuss. >>>> >>> >>> What can be done in the different SAVI documents, is to restrict >>> logging only when an incident has been detected (i.e. use of an IP >>> address not allowed on a binding anchor). >>> >>> Would it be fine for you? >> >> Only logging when an incident has been detected sounds >> perfect to me. >> >> Thanks for considering this, >> Regards, >> Stephen. >> >> > > [snip] > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jeanmichel.combes@gmail.com Tue Jun 21 06:37: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 5D0E011E809F for ; Tue, 21 Jun 2011 06:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 g2jYUSlpFvOX for ; Tue, 21 Jun 2011 06:37:46 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41EA011E8096 for ; Tue, 21 Jun 2011 06:37:38 -0700 (PDT) Received: by ywp31 with SMTP id 31so3772633ywp.31 for ; Tue, 21 Jun 2011 06:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=2icds/Qd3yWcNjJ5i+mcytb4QqjkyOGPtjJM2W5wU70=; b=YHEOxvkJAI8txevEpBMcQ/8ynaMuEdbiS7QgtQf4WGnLNnMFuieMmi54G8c1yoHeO5 z7ybHGf8aCJiUx111cjXZkz733EZKF5tG5chYXs24ZGEXcPnwzL5WPdofPy9aIj5IlVB 77kIry12d8+5hfc8qczzq/YspSpwMP/qrQ5uU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=td7O74Pc+kSV0ev7OHsF5dFw0taKS6KjAXUL4GV/kc2MafgqG8XrKi0dyyCtZWfZr7 5h0AJHnI0BuhaaYvcQRHMaapAbUJHspahl2Tbw1CKKQXcBTOj2GgowMgWo9nGhqD7ids EirU/M8cJhtOwFpUYcAUKexV2rIdVA2tJsIzE= MIME-Version: 1.0 Received: by 10.236.190.170 with SMTP id e30mr11033061yhn.226.1308663456711; Tue, 21 Jun 2011 06:37:36 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Tue, 21 Jun 2011 06:37:36 -0700 (PDT) Date: Tue, 21 Jun 2011 15:37:36 +0200 Message-ID: From: Jean-Michel Combes To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1 Subject: [savi] Potential issue for all SAVI mechanisms? 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, 21 Jun 2011 13:37:47 -0000 Hi, Maybe you already know that there is a discussion on v6ops/6man MLs about RA Guard evasion (cf. http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). One of the methods to perform this evasion is fragmentation: it seems that a L2 device would not be able to re-assemble all the fragments without an important extra-cost and so would not be able to determine whether or not the message is a Router Advertisement (cf. http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). Knowing that: (1) In common use-case, SAVI device is a L2 device (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection I am wondering whether or not fragmentation would not impact strongly SAVI specifications too: any fragmented NDP/SEND/DHCP message could not update correctly the Binding Table and so what would be the consequences? I would appreciate comments from WG members, especially implementors/manufacturers, about this. Thanks in advance for your replies. Best regards. JMC. From junbi@cernet.edu.cn Tue Jun 21 06:56:44 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 21BFF9E801F for ; Tue, 21 Jun 2011 06:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.902 X-Spam-Level: X-Spam-Status: No, score=-99.902 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, STOX_REPLY_TYPE=0.001, 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 S4ld+gQeACVw for ; Tue, 21 Jun 2011 06:56:43 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 4DA5E9E8014 for ; Tue, 21 Jun 2011 06:56:41 -0700 (PDT) Received: from junbiVAIOz138([59.66.24.191]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm144e00bff4; Tue, 21 Jun 2011 21:56:38 +0800 Message-ID: From: "Jun Bi" To: "Jean-Michel Combes" , "SAVI Mailing List" References: In-Reply-To: Date: Tue, 21 Jun 2011 21:56:34 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original 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: M161B90B Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 21 Jun 2011 13:56:44 -0000 Hi Jean-Michel, What we are talking about "savi switch" is a 2.5 layer switch (layer 2 switch in data plan with layer 3-aware in controll/management plan). So what I know from switch vendor is that the 2.5 layer switch chip or the stronger CPU can handel it. For example, the chip can recongnize the Protocol ID field of IP packets to recongznie HDCP or NDP packets (even in fragments), then copy them to switch CPU. The CPU can handle it. The SAVI switch has been really implmented and deployed, so I did really see any problem in real network. BTW, it seems that SAVI switch doesn't snoop and process RA packets for binding, so maybe RA packet is different. thanks, Jun Bi -----原始邮件----- From: Jean-Michel Combes Sent: Tuesday, June 21, 2011 9:37 PM To: SAVI Mailing List Subject: [savi] Potential issue for all SAVI mechanisms? Hi, Maybe you already know that there is a discussion on v6ops/6man MLs about RA Guard evasion (cf. http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). One of the methods to perform this evasion is fragmentation: it seems that a L2 device would not be able to re-assemble all the fragments without an important extra-cost and so would not be able to determine whether or not the message is a Router Advertisement (cf. http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). Knowing that: (1) In common use-case, SAVI device is a L2 device (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection I am wondering whether or not fragmentation would not impact strongly SAVI specifications too: any fragmented NDP/SEND/DHCP message could not update correctly the Binding Table and so what would be the consequences? I would appreciate comments from WG members, especially implementors/manufacturers, about this. Thanks in advance for your replies. Best regards. JMC. _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From jmh@joelhalpern.com Tue Jun 21 17:17: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 CE18611E80A7 for ; Tue, 21 Jun 2011 17:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, 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 J5riDBaXeIuS for ; Tue, 21 Jun 2011 17:17:40 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id EF01E11E8088 for ; Tue, 21 Jun 2011 17:17:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id D204C324657F; Tue, 21 Jun 2011 17:17:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.154.181.49] (unknown [129.192.185.163]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 3B5F73246570; Tue, 21 Jun 2011 17:17:09 -0700 (PDT) Message-ID: <4E013482.3080405@joelhalpern.com> Date: Tue, 21 Jun 2011 20:17:06 -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: Jun Bi References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: SAVI Mailing List , Jean-Michel Combes Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 22 Jun 2011 00:17:44 -0000 I do not think this is a sufficient answer. Whether the device is a switch or a router, reassembling or maintaining packet state across fragements is a non-trivial undertaking. I can imagine some kludges to get around this, but they have broader impact than just SAVI. (For example, rejecting first packets that do not have enough information to determine whether or not they are claiming to be RAs or DHCP replies.) Yours, Joel On 6/21/2011 9:56 AM, Jun Bi wrote: > Hi Jean-Michel, > > What we are talking about "savi switch" is a 2.5 layer switch (layer 2 > switch in data plan with layer 3-aware in controll/management plan). > So what I know from switch vendor is that the 2.5 layer switch chip or > the stronger CPU can handel it. > For example, the chip can recongnize the Protocol ID field of IP packets > to recongznie HDCP or NDP packets (even in fragments), > then copy them to switch CPU. The CPU can handle it. > > The SAVI switch has been really implmented and deployed, so I did really > see any problem in real network. > BTW, it seems that SAVI switch doesn't snoop and process RA packets for > binding, so maybe RA packet is different. > > thanks, > Jun Bi > > -----原始邮件----- From: Jean-Michel Combes > Sent: Tuesday, June 21, 2011 9:37 PM > To: SAVI Mailing List > Subject: [savi] Potential issue for all SAVI mechanisms? > > Hi, > > Maybe you already know that there is a discussion on v6ops/6man MLs > about RA Guard evasion (cf. > http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). > One of the methods to perform this evasion is fragmentation: it seems > that a L2 device would not be able to re-assemble all the fragments > without an important extra-cost and so would not be able to determine > whether or not the message is a Router Advertisement (cf. > http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). > > Knowing that: > (1) In common use-case, SAVI device is a L2 device > (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection > > I am wondering whether or not fragmentation would not impact strongly > SAVI specifications too: any fragmented NDP/SEND/DHCP message could > not update correctly the Binding Table and so what would be the > consequences? > > I would appreciate comments from WG members, especially > implementors/manufacturers, about this. > > Thanks in advance for your replies. > > Best regards. > > JMC. > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From junbi@cernet.edu.cn Tue Jun 21 21:40: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 46C1C11E8079 for ; Tue, 21 Jun 2011 21:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 r3AEoyb71WMG for ; Tue, 21 Jun 2011 21:40:08 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 0F47211E80A0 for ; Tue, 21 Jun 2011 21:40:03 -0700 (PDT) Received: from junbiVAIOz138([59.66.53.212]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm54e018f00; Wed, 22 Jun 2011 12:40:02 +0800 Message-ID: <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> From: "Jun Bi" To: "Joel M. Halpern" References: <4E013482.3080405@joelhalpern.com> In-Reply-To: <4E013482.3080405@joelhalpern.com> Date: Wed, 22 Jun 2011 12:35:48 +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: MO0OP90B Cc: SAVI Mailing List , Jean-Michel Combes Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 22 Jun 2011 04:40:09 -0000 In the Ethernet environment, the MTU is 1500, DHCP reply is not a large packet and it won't be fragmented. Maybe the packet size of RA is large and might be fragmented, but it is not processed in SAVI. thanks, Jun Bi -----原始邮件----- From: Joel M. Halpern Sent: Wednesday, June 22, 2011 8:17 AM To: Jun Bi Cc: Jean-Michel Combes ; SAVI Mailing List Subject: Re: [savi] Potential issue for all SAVI mechanisms? I do not think this is a sufficient answer. Whether the device is a switch or a router, reassembling or maintaining packet state across fragements is a non-trivial undertaking. I can imagine some kludges to get around this, but they have broader impact than just SAVI. (For example, rejecting first packets that do not have enough information to determine whether or not they are claiming to be RAs or DHCP replies.) Yours, Joel On 6/21/2011 9:56 AM, Jun Bi wrote: > Hi Jean-Michel, > > What we are talking about "savi switch" is a 2.5 layer switch (layer 2 > switch in data plan with layer 3-aware in controll/management plan). > So what I know from switch vendor is that the 2.5 layer switch chip or > the stronger CPU can handel it. > For example, the chip can recongnize the Protocol ID field of IP packets > to recongznie HDCP or NDP packets (even in fragments), > then copy them to switch CPU. The CPU can handle it. > > The SAVI switch has been really implmented and deployed, so I did really > see any problem in real network. > BTW, it seems that SAVI switch doesn't snoop and process RA packets for > binding, so maybe RA packet is different. > > thanks, > Jun Bi > > -----原始邮件----- From: Jean-Michel Combes > Sent: Tuesday, June 21, 2011 9:37 PM > To: SAVI Mailing List > Subject: [savi] Potential issue for all SAVI mechanisms? > > Hi, > > Maybe you already know that there is a discussion on v6ops/6man MLs > about RA Guard evasion (cf. > http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). > One of the methods to perform this evasion is fragmentation: it seems > that a L2 device would not be able to re-assemble all the fragments > without an important extra-cost and so would not be able to determine > whether or not the message is a Router Advertisement (cf. > http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). > > Knowing that: > (1) In common use-case, SAVI device is a L2 device > (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection > > I am wondering whether or not fragmentation would not impact strongly > SAVI specifications too: any fragmented NDP/SEND/DHCP message could > not update correctly the Binding Table and so what would be the > consequences? > > I would appreciate comments from WG members, especially > implementors/manufacturers, about this. > > Thanks in advance for your replies. > > Best regards. > > JMC. > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From jmh@joelhalpern.com Tue Jun 21 22:12:34 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 0132011E80D2 for ; Tue, 21 Jun 2011 22:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=1.150, 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 FDom+S24h9OU for ; Tue, 21 Jun 2011 22:12:32 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 687BE11E8074 for ; Tue, 21 Jun 2011 22:12:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 449E532464AF; Tue, 21 Jun 2011 22:12:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 29DB132465A8; Tue, 21 Jun 2011 22:12:01 -0700 (PDT) Message-ID: <4E01799E.7010109@joelhalpern.com> Date: Wed, 22 Jun 2011 01:11:58 -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: Jun Bi References: <4E013482.3080405@joelhalpern.com> <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> In-Reply-To: <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: SAVI Mailing List Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 22 Jun 2011 05:12:34 -0000 You are missing the point. There is no rule that prevents a legitimate host from choosing to fragment the packets. Therefore, we can not simply drop short fragments. This means that a malicious device can choose to generate short fragments in order to mislead the filters. It can not mislead the filters about the IP address. But it can create false DHCP replies or RAs. The net effect would be to cause hosts to be unable to communicate, since they would be using improper addresses. yours, Joel On 6/22/2011 12:35 AM, Jun Bi wrote: > In the Ethernet environment, the MTU is 1500, DHCP reply is not a large > packet and it won't be fragmented. > Maybe the packet size of RA is large and might be fragmented, but it is > not processed in SAVI. > > thanks, > Jun Bi > > -----原始邮件----- From: Joel M. Halpern > Sent: Wednesday, June 22, 2011 8:17 AM > To: Jun Bi > Cc: Jean-Michel Combes ; SAVI Mailing List > Subject: Re: [savi] Potential issue for all SAVI mechanisms? > > I do not think this is a sufficient answer. Whether the device is a > switch or a router, reassembling or maintaining packet state across > fragements is a non-trivial undertaking. > > I can imagine some kludges to get around this, but they have broader > impact than just SAVI. (For example, rejecting first packets that do > not have enough information to determine whether or not they are > claiming to be RAs or DHCP replies.) > > Yours, > Joel > > On 6/21/2011 9:56 AM, Jun Bi wrote: >> Hi Jean-Michel, >> >> What we are talking about "savi switch" is a 2.5 layer switch (layer 2 >> switch in data plan with layer 3-aware in controll/management plan). >> So what I know from switch vendor is that the 2.5 layer switch chip or >> the stronger CPU can handel it. >> For example, the chip can recongnize the Protocol ID field of IP packets >> to recongznie HDCP or NDP packets (even in fragments), >> then copy them to switch CPU. The CPU can handle it. >> >> The SAVI switch has been really implmented and deployed, so I did really >> see any problem in real network. >> BTW, it seems that SAVI switch doesn't snoop and process RA packets for >> binding, so maybe RA packet is different. >> >> thanks, >> Jun Bi >> >> -----原始邮件----- From: Jean-Michel Combes >> Sent: Tuesday, June 21, 2011 9:37 PM >> To: SAVI Mailing List >> Subject: [savi] Potential issue for all SAVI mechanisms? >> >> Hi, >> >> Maybe you already know that there is a discussion on v6ops/6man MLs >> about RA Guard evasion (cf. >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). >> One of the methods to perform this evasion is fragmentation: it seems >> that a L2 device would not be able to re-assemble all the fragments >> without an important extra-cost and so would not be able to determine >> whether or not the message is a Router Advertisement (cf. >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). >> >> Knowing that: >> (1) In common use-case, SAVI device is a L2 device >> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection >> >> I am wondering whether or not fragmentation would not impact strongly >> SAVI specifications too: any fragmented NDP/SEND/DHCP message could >> not update correctly the Binding Table and so what would be the >> consequences? >> >> I would appreciate comments from WG members, especially >> implementors/manufacturers, about this. >> >> Thanks in advance for your replies. >> >> Best regards. >> >> JMC. >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > From marcelo@it.uc3m.es Tue Jun 21 22:26: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 1D71C11E8094 for ; Tue, 21 Jun 2011 22:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 K3iO0JpPDzVx for ; Tue, 21 Jun 2011 22:26:39 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id 226D811E8091 for ; Tue, 21 Jun 2011 22:26:38 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 6A2A2711B70 for ; Wed, 22 Jun 2011 07:26:37 +0200 (CEST) Message-ID: <4E017D0B.8090301@it.uc3m.es> Date: Wed, 22 Jun 2011 07:26:35 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: savi@ietf.org References: <4E013482.3080405@joelhalpern.com> <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> In-Reply-To: <70DEE8BFA1794CA9B6694032363C3460@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-18214.003 Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 22 Jun 2011 05:26:40 -0000 Right, the question is how comon is for legitimate users to send NDP/DHCP/SEND fragmented packets? IS there any concrete real useful situacion where this happens? If not, maybe we could simply say that SAVI will ignore the fragmented packets. If yes, then it seems we may have a problem. Regards, marcelo El 22/06/11 06:35, Jun Bi escribió: > In the Ethernet environment, the MTU is 1500, DHCP reply is not a > large packet and it won't be fragmented. > Maybe the packet size of RA is large and might be fragmented, but it > is not processed in SAVI. > > thanks, > Jun Bi > > -----原始邮件----- From: Joel M. Halpern > Sent: Wednesday, June 22, 2011 8:17 AM > To: Jun Bi > Cc: Jean-Michel Combes ; SAVI Mailing List > Subject: Re: [savi] Potential issue for all SAVI mechanisms? > > I do not think this is a sufficient answer. Whether the device is a > switch or a router, reassembling or maintaining packet state across > fragements is a non-trivial undertaking. > > I can imagine some kludges to get around this, but they have broader > impact than just SAVI. (For example, rejecting first packets that do > not have enough information to determine whether or not they are > claiming to be RAs or DHCP replies.) > > Yours, > Joel > > On 6/21/2011 9:56 AM, Jun Bi wrote: >> Hi Jean-Michel, >> >> What we are talking about "savi switch" is a 2.5 layer switch (layer 2 >> switch in data plan with layer 3-aware in controll/management plan). >> So what I know from switch vendor is that the 2.5 layer switch chip or >> the stronger CPU can handel it. >> For example, the chip can recongnize the Protocol ID field of IP packets >> to recongznie HDCP or NDP packets (even in fragments), >> then copy them to switch CPU. The CPU can handle it. >> >> The SAVI switch has been really implmented and deployed, so I did really >> see any problem in real network. >> BTW, it seems that SAVI switch doesn't snoop and process RA packets for >> binding, so maybe RA packet is different. >> >> thanks, >> Jun Bi >> >> -----原始邮件----- From: Jean-Michel Combes >> Sent: Tuesday, June 21, 2011 9:37 PM >> To: SAVI Mailing List >> Subject: [savi] Potential issue for all SAVI mechanisms? >> >> Hi, >> >> Maybe you already know that there is a discussion on v6ops/6man MLs >> about RA Guard evasion (cf. >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). >> One of the methods to perform this evasion is fragmentation: it seems >> that a L2 device would not be able to re-assemble all the fragments >> without an important extra-cost and so would not be able to determine >> whether or not the message is a Router Advertisement (cf. >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). >> >> Knowing that: >> (1) In common use-case, SAVI device is a L2 device >> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection >> >> I am wondering whether or not fragmentation would not impact strongly >> SAVI specifications too: any fragmented NDP/SEND/DHCP message could >> not update correctly the Binding Table and so what would be the >> consequences? >> >> I would appreciate comments from WG members, especially >> implementors/manufacturers, about this. >> >> Thanks in advance for your replies. >> >> Best regards. >> >> JMC. >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From marcelo@it.uc3m.es Tue Jun 21 22:32: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 AF47511E80AD for ; Tue, 21 Jun 2011 22:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.134 X-Spam-Level: X-Spam-Status: No, score=-106.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 EitPNe2U7Gcl for ; Tue, 21 Jun 2011 22:32:35 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id B848911E80A3 for ; Tue, 21 Jun 2011 22:32:34 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro-2.local (wlap005.it.uc3m.es [163.117.139.108]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 7219B7053B1 for ; Wed, 22 Jun 2011 07:32:33 +0200 (CEST) Message-ID: <4E017E70.9020907@it.uc3m.es> Date: Wed, 22 Jun 2011 07:32:32 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; es-ES; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: savi@ietf.org References: <4E013482.3080405@joelhalpern.com> <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> <4E01799E.7010109@joelhalpern.com> In-Reply-To: <4E01799E.7010109@joelhalpern.com> 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-18214.003 Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 22 Jun 2011 05:32:35 -0000 Right, for the SLAAC case we should differentiate two cases: the case of RA and the case of NS and NA. The case of RA i think it is easy to solve. Only RA coming from trusted ports should be processed and if you have an attacker there you have bigger problems than the possibility of receiving fragmented RAs. The current SLAAC draft doesn states that a SAVI device must only process RA coming from trusted ports, but i think we should add text about this. The case of NA and NS is much more difficult to handle since they are the main messages used by non trusted hosts/ports. In this case, i still think that it would be importnat to understnad if there is reasonable cases where a legitimate user needs to send fragmented NA and NS. Regards, marcelo El 22/06/11 07:11, Joel M. Halpern escribió: > You are missing the point. > There is no rule that prevents a legitimate host from choosing to > fragment the packets. > Therefore, we can not simply drop short fragments. > This means that a malicious device can choose to generate short > fragments in order to mislead the filters. It can not mislead the > filters about the IP address. But it can create false DHCP replies or > RAs. > > The net effect would be to cause hosts to be unable to communicate, > since they would be using improper addresses. > > yours, > Joel > > On 6/22/2011 12:35 AM, Jun Bi wrote: >> In the Ethernet environment, the MTU is 1500, DHCP reply is not a large >> packet and it won't be fragmented. >> Maybe the packet size of RA is large and might be fragmented, but it is >> not processed in SAVI. >> >> thanks, >> Jun Bi >> >> -----原始邮件----- From: Joel M. Halpern >> Sent: Wednesday, June 22, 2011 8:17 AM >> To: Jun Bi >> Cc: Jean-Michel Combes ; SAVI Mailing List >> Subject: Re: [savi] Potential issue for all SAVI mechanisms? >> >> I do not think this is a sufficient answer. Whether the device is a >> switch or a router, reassembling or maintaining packet state across >> fragements is a non-trivial undertaking. >> >> I can imagine some kludges to get around this, but they have broader >> impact than just SAVI. (For example, rejecting first packets that do >> not have enough information to determine whether or not they are >> claiming to be RAs or DHCP replies.) >> >> Yours, >> Joel >> >> On 6/21/2011 9:56 AM, Jun Bi wrote: >>> Hi Jean-Michel, >>> >>> What we are talking about "savi switch" is a 2.5 layer switch (layer 2 >>> switch in data plan with layer 3-aware in controll/management plan). >>> So what I know from switch vendor is that the 2.5 layer switch chip or >>> the stronger CPU can handel it. >>> For example, the chip can recongnize the Protocol ID field of IP >>> packets >>> to recongznie HDCP or NDP packets (even in fragments), >>> then copy them to switch CPU. The CPU can handle it. >>> >>> The SAVI switch has been really implmented and deployed, so I did >>> really >>> see any problem in real network. >>> BTW, it seems that SAVI switch doesn't snoop and process RA packets for >>> binding, so maybe RA packet is different. >>> >>> thanks, >>> Jun Bi >>> >>> -----原始邮件----- From: Jean-Michel Combes >>> Sent: Tuesday, June 21, 2011 9:37 PM >>> To: SAVI Mailing List >>> Subject: [savi] Potential issue for all SAVI mechanisms? >>> >>> Hi, >>> >>> Maybe you already know that there is a discussion on v6ops/6man MLs >>> about RA Guard evasion (cf. >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). >>> One of the methods to perform this evasion is fragmentation: it seems >>> that a L2 device would not be able to re-assemble all the fragments >>> without an important extra-cost and so would not be able to determine >>> whether or not the message is a Router Advertisement (cf. >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). >>> >>> Knowing that: >>> (1) In common use-case, SAVI device is a L2 device >>> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection >>> >>> I am wondering whether or not fragmentation would not impact strongly >>> SAVI specifications too: any fragmented NDP/SEND/DHCP message could >>> not update correctly the Binding Table and so what would be the >>> consequences? >>> >>> I would appreciate comments from WG members, especially >>> implementors/manufacturers, about this. >>> >>> Thanks in advance for your replies. >>> >>> Best regards. >>> >>> JMC. >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From junbi@cernet.edu.cn Tue Jun 21 23:13: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 15C9911E8094 for ; Tue, 21 Jun 2011 23:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 DZaFRm1XKUBW for ; Tue, 21 Jun 2011 23:13:16 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 84F3011E8090 for ; Tue, 21 Jun 2011 23:13:12 -0700 (PDT) Received: from junbiVAIOz138([59.66.24.191]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm124e01a4d0; Wed, 22 Jun 2011 14:13:06 +0800 Message-ID: From: "Jun Bi" To: "marcelo bagnulo braun" , References: <4E013482.3080405@joelhalpern.com> <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138><4E01799E.7010109@joelhalpern.com> <4E017E70.9020907@it.uc3m.es> In-Reply-To: <4E017E70.9020907@it.uc3m.es> Date: Wed, 22 Jun 2011 14:13:06 +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: MA4gQ90B Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 22 Jun 2011 06:13:17 -0000 For DHCP reply, it is the samilar case at RA turst port, it can be handled only at DHCP-TRUST port. thanks, Jun -----原始邮件----- From: marcelo bagnulo braun Sent: Wednesday, June 22, 2011 1:32 PM To: savi@ietf.org Subject: Re: [savi] Potential issue for all SAVI mechanisms? Right, for the SLAAC case we should differentiate two cases: the case of RA and the case of NS and NA. The case of RA i think it is easy to solve. Only RA coming from trusted ports should be processed and if you have an attacker there you have bigger problems than the possibility of receiving fragmented RAs. The current SLAAC draft doesn states that a SAVI device must only process RA coming from trusted ports, but i think we should add text about this. The case of NA and NS is much more difficult to handle since they are the main messages used by non trusted hosts/ports. In this case, i still think that it would be importnat to understnad if there is reasonable cases where a legitimate user needs to send fragmented NA and NS. Regards, marcelo El 22/06/11 07:11, Joel M. Halpern escribió: > You are missing the point. > There is no rule that prevents a legitimate host from choosing to fragment > the packets. > Therefore, we can not simply drop short fragments. > This means that a malicious device can choose to generate short fragments > in order to mislead the filters. It can not mislead the filters about the > IP address. But it can create false DHCP replies or RAs. > > The net effect would be to cause hosts to be unable to communicate, since > they would be using improper addresses. > > yours, > Joel > > On 6/22/2011 12:35 AM, Jun Bi wrote: >> In the Ethernet environment, the MTU is 1500, DHCP reply is not a large >> packet and it won't be fragmented. >> Maybe the packet size of RA is large and might be fragmented, but it is >> not processed in SAVI. >> >> thanks, >> Jun Bi >> >> -----原始邮件----- From: Joel M. Halpern >> Sent: Wednesday, June 22, 2011 8:17 AM >> To: Jun Bi >> Cc: Jean-Michel Combes ; SAVI Mailing List >> Subject: Re: [savi] Potential issue for all SAVI mechanisms? >> >> I do not think this is a sufficient answer. Whether the device is a >> switch or a router, reassembling or maintaining packet state across >> fragements is a non-trivial undertaking. >> >> I can imagine some kludges to get around this, but they have broader >> impact than just SAVI. (For example, rejecting first packets that do >> not have enough information to determine whether or not they are >> claiming to be RAs or DHCP replies.) >> >> Yours, >> Joel >> >> On 6/21/2011 9:56 AM, Jun Bi wrote: >>> Hi Jean-Michel, >>> >>> What we are talking about "savi switch" is a 2.5 layer switch (layer 2 >>> switch in data plan with layer 3-aware in controll/management plan). >>> So what I know from switch vendor is that the 2.5 layer switch chip or >>> the stronger CPU can handel it. >>> For example, the chip can recongnize the Protocol ID field of IP packets >>> to recongznie HDCP or NDP packets (even in fragments), >>> then copy them to switch CPU. The CPU can handle it. >>> >>> The SAVI switch has been really implmented and deployed, so I did really >>> see any problem in real network. >>> BTW, it seems that SAVI switch doesn't snoop and process RA packets for >>> binding, so maybe RA packet is different. >>> >>> thanks, >>> Jun Bi >>> >>> -----原始邮件----- From: Jean-Michel Combes >>> Sent: Tuesday, June 21, 2011 9:37 PM >>> To: SAVI Mailing List >>> Subject: [savi] Potential issue for all SAVI mechanisms? >>> >>> Hi, >>> >>> Maybe you already know that there is a discussion on v6ops/6man MLs >>> about RA Guard evasion (cf. >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). >>> One of the methods to perform this evasion is fragmentation: it seems >>> that a L2 device would not be able to re-assemble all the fragments >>> without an important extra-cost and so would not be able to determine >>> whether or not the message is a Router Advertisement (cf. >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). >>> >>> Knowing that: >>> (1) In common use-case, SAVI device is a L2 device >>> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection >>> >>> I am wondering whether or not fragmentation would not impact strongly >>> SAVI specifications too: any fragmented NDP/SEND/DHCP message could >>> not update correctly the Binding Table and so what would be the >>> consequences? >>> >>> I would appreciate comments from WG members, especially >>> implementors/manufacturers, about this. >>> >>> Thanks in advance for your replies. >>> >>> Best regards. >>> >>> JMC. >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From swmike@swm.pp.se Tue Jun 21 23:27:45 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 15CFA11E80A7 for ; Tue, 21 Jun 2011 23:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 q1ijdJv5CbT6 for ; Tue, 21 Jun 2011 23:27:44 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 39A5B11E8070 for ; Tue, 21 Jun 2011 23:27:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id DD9919C; Wed, 22 Jun 2011 08:27:41 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D828C9A for ; Wed, 22 Jun 2011 08:27:41 +0200 (CEST) Date: Wed, 22 Jun 2011 08:27:41 +0200 (CEST) From: Mikael Abrahamsson To: savi@ietf.org In-Reply-To: <4E017D0B.8090301@it.uc3m.es> Message-ID: References: <4E013482.3080405@joelhalpern.com> <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> <4E017D0B.8090301@it.uc3m.es> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 22 Jun 2011 06:27:45 -0000 On Wed, 22 Jun 2011, marcelo bagnulo braun wrote: > If not, maybe we could simply say that SAVI will ignore the fragmented > packets. What do you mean by "ignore", do you mean drop? It's my firm belief that any security measure needs to take into account these corner cases and properly handle them (with the same security), allowing anyone to send RA just because they're sending them fragmented is not ok. It's better to drop these packets than to allow them. -- Mikael Abrahamsson email: swmike@swm.pp.se From junbi@cernet.edu.cn Tue Jun 21 23:37:01 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 7D2D811E8083 for ; Tue, 21 Jun 2011 23:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.903 X-Spam-Level: X-Spam-Status: No, score=-99.903 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 XhshzwZkZcIv for ; Tue, 21 Jun 2011 23:37:01 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id 8A87511E8070 for ; Tue, 21 Jun 2011 23:36:59 -0700 (PDT) Received: from junbiVAIOz138([59.66.24.191]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm104e01aa67; Wed, 22 Jun 2011 14:36:57 +0800 Message-ID: From: "Jun Bi" To: "Joel M. Halpern" References: <4E013482.3080405@joelhalpern.com> <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> <4E01799E.7010109@joelhalpern.com> In-Reply-To: <4E01799E.7010109@joelhalpern.com> Date: Wed, 22 Jun 2011 14:36:56 +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: Mf9DR90B Cc: SAVI Mailing List Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 22 Jun 2011 06:37:01 -0000 Hi Joel, I meant, in my first eamil I said, in theory, the savi switch can process the fragmentation. This is common function in network device. (and the switch can only process dhcp-reply at dhcp-trust port). In my last email, I meant, in practical, it won't be a big issue. thanks, Jun Bi -----原始邮件----- From: Joel M. Halpern Sent: Wednesday, June 22, 2011 1:11 PM To: Jun Bi Cc: SAVI Mailing List Subject: Re: [savi] Potential issue for all SAVI mechanisms? You are missing the point. There is no rule that prevents a legitimate host from choosing to fragment the packets. Therefore, we can not simply drop short fragments. This means that a malicious device can choose to generate short fragments in order to mislead the filters. It can not mislead the filters about the IP address. But it can create false DHCP replies or RAs. The net effect would be to cause hosts to be unable to communicate, since they would be using improper addresses. yours, Joel On 6/22/2011 12:35 AM, Jun Bi wrote: > In the Ethernet environment, the MTU is 1500, DHCP reply is not a large > packet and it won't be fragmented. > Maybe the packet size of RA is large and might be fragmented, but it is > not processed in SAVI. > > thanks, > Jun Bi > > -----原始邮件----- From: Joel M. Halpern > Sent: Wednesday, June 22, 2011 8:17 AM > To: Jun Bi > Cc: Jean-Michel Combes ; SAVI Mailing List > Subject: Re: [savi] Potential issue for all SAVI mechanisms? > > I do not think this is a sufficient answer. Whether the device is a > switch or a router, reassembling or maintaining packet state across > fragements is a non-trivial undertaking. > > I can imagine some kludges to get around this, but they have broader > impact than just SAVI. (For example, rejecting first packets that do > not have enough information to determine whether or not they are > claiming to be RAs or DHCP replies.) > > Yours, > Joel > > On 6/21/2011 9:56 AM, Jun Bi wrote: >> Hi Jean-Michel, >> >> What we are talking about "savi switch" is a 2.5 layer switch (layer 2 >> switch in data plan with layer 3-aware in controll/management plan). >> So what I know from switch vendor is that the 2.5 layer switch chip or >> the stronger CPU can handel it. >> For example, the chip can recongnize the Protocol ID field of IP packets >> to recongznie HDCP or NDP packets (even in fragments), >> then copy them to switch CPU. The CPU can handle it. >> >> The SAVI switch has been really implmented and deployed, so I did really >> see any problem in real network. >> BTW, it seems that SAVI switch doesn't snoop and process RA packets for >> binding, so maybe RA packet is different. >> >> thanks, >> Jun Bi >> >> -----原始邮件----- From: Jean-Michel Combes >> Sent: Tuesday, June 21, 2011 9:37 PM >> To: SAVI Mailing List >> Subject: [savi] Potential issue for all SAVI mechanisms? >> >> Hi, >> >> Maybe you already know that there is a discussion on v6ops/6man MLs >> about RA Guard evasion (cf. >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). >> One of the methods to perform this evasion is fragmentation: it seems >> that a L2 device would not be able to re-assemble all the fragments >> without an important extra-cost and so would not be able to determine >> whether or not the message is a Router Advertisement (cf. >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). >> >> Knowing that: >> (1) In common use-case, SAVI device is a L2 device >> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection >> >> I am wondering whether or not fragmentation would not impact strongly >> SAVI specifications too: any fragmented NDP/SEND/DHCP message could >> not update correctly the Binding Table and so what would be the >> consequences? >> >> I would appreciate comments from WG members, especially >> implementors/manufacturers, about this. >> >> Thanks in advance for your replies. >> >> Best regards. >> >> JMC. >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > From alberto@it.uc3m.es Wed Jun 22 03:41: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 6FA9311E80CF for ; Wed, 22 Jun 2011 03:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 qulcWZ-+8KLm for ; Wed, 22 Jun 2011 03:41:05 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8EC11E8076 for ; Wed, 22 Jun 2011 03:41:05 -0700 (PDT) X-uc3m-safe: yes Received: from BOMBO (unknown [163.117.139.42]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id CEE61BDFDE2; Wed, 22 Jun 2011 12:39:21 +0200 (CEST) From: =?utf-8?Q?Alberto_Garc=C3=ADa?= To: "'Jun Bi'" , "'Joel M. Halpern'" References: <4E013482.3080405@joelhalpern.com> <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> <4E01799E.7010109@joelhalpern.com> In-Reply-To: Date: Wed, 22 Jun 2011 12:39:23 +0200 Message-ID: <001901cc30c8$a6b95ce0$f42c16a0$@it.uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKZ/DDGfZMDB5TElyYu2/eSzb1K8gGglDgyAY3EfaQCJLmQXQLDU5JzAoEI9A+S2NblQA== Content-language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-18214.006 Cc: 'SAVI Mailing List' Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 22 Jun 2011 10:41:06 -0000 Hi, For the SEND case, the validation mechanism requires cryptographic = processing from the switches, which should be very likely performed by = the CPU of the switch. IMHO, the increased cost and burden of requiring = fragmentation processing just for the specific messages being used by = SEND SAVI should not be high compared to the cost of implementing the = SEND SAVI mechanism.=20 For this case, the 'Security Considerations' section could include some = comment to rate-limit this processing to counter a possible DoS attack = using fragmented packets (although, again, it would very likely be more = effective an attack forcing the switch to perform the validation for = invalid SEND messages - as it is currently discussed in the 'Security = Considerations') Regards, Alberto | -----Mensaje original----- | De: savi-bounces@ietf.org [mailto:savi-bounces@ietf.org] En nombre de | Jun Bi | Enviado el: mi=C3=A9rcoles, 22 de junio de 2011 8:37 | Para: Joel M. Halpern | CC: SAVI Mailing List | Asunto: Re: [savi] Potential issue for all SAVI mechanisms? | =20 | Hi Joel, | =20 | I meant, in my first eamil I said, in theory, the savi switch can = process the | fragmentation. This is common function in network device. | (and the switch can only process dhcp-reply at dhcp-trust port). | =20 | In my last email, I meant, in practical, it won't be a big issue. | =20 | thanks, | Jun Bi | -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- | From: Joel M. Halpern | Sent: Wednesday, June 22, 2011 1:11 PM | To: Jun Bi | Cc: SAVI Mailing List | Subject: Re: [savi] Potential issue for all SAVI mechanisms? | =20 | You are missing the point. | There is no rule that prevents a legitimate host from choosing to = fragment | the packets. | Therefore, we can not simply drop short fragments. | This means that a malicious device can choose to generate short = fragments | in order to mislead the filters. It can not mislead the filters = about the IP | address. But it can create false DHCP replies or RAs. | =20 | The net effect would be to cause hosts to be unable to communicate, = since | they would be using improper addresses. | =20 | yours, | Joel | =20 | On 6/22/2011 12:35 AM, Jun Bi wrote: | > In the Ethernet environment, the MTU is 1500, DHCP reply is not a | > large packet and it won't be fragmented. | > Maybe the packet size of RA is large and might be fragmented, but = it | > is not processed in SAVI. | > | > thanks, | > Jun Bi | > | > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Joel M. = Halpern | > Sent: Wednesday, June 22, 2011 8:17 AM | > To: Jun Bi | > Cc: Jean-Michel Combes ; SAVI Mailing List | > Subject: Re: [savi] Potential issue for all SAVI mechanisms? | > | > I do not think this is a sufficient answer. Whether the device is a | > switch or a router, reassembling or maintaining packet state across | > fragements is a non-trivial undertaking. | > | > I can imagine some kludges to get around this, but they have = broader | > impact than just SAVI. (For example, rejecting first packets that = do | > not have enough information to determine whether or not they are | > claiming to be RAs or DHCP replies.) | > | > Yours, | > Joel | > | > On 6/21/2011 9:56 AM, Jun Bi wrote: | >> Hi Jean-Michel, | >> | >> What we are talking about "savi switch" is a 2.5 layer switch = (layer | >> 2 switch in data plan with layer 3-aware in controll/management = plan). | >> So what I know from switch vendor is that the 2.5 layer switch = chip | >> or the stronger CPU can handel it. | >> For example, the chip can recongnize the Protocol ID field of IP | >> packets to recongznie HDCP or NDP packets (even in fragments), = then | >> copy them to switch CPU. The CPU can handle it. | >> | >> The SAVI switch has been really implmented and deployed, so I did | >> really see any problem in real network. | >> BTW, it seems that SAVI switch doesn't snoop and process RA = packets | >> for binding, so maybe RA packet is different. | >> | >> thanks, | >> Jun Bi | >> | >> -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Jean-Michel = Combes | >> Sent: Tuesday, June 21, 2011 9:37 PM | >> To: SAVI Mailing List | >> Subject: [savi] Potential issue for all SAVI mechanisms? | >> | >> Hi, | >> | >> Maybe you already know that there is a discussion on v6ops/6man = MLs | >> about RA Guard evasion (cf. | >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). | >> One of the methods to perform this evasion is fragmentation: it = seems | >> that a L2 device would not be able to re-assemble all the = fragments | >> without an important extra-cost and so would not be able to = determine | >> whether or not the message is a Router Advertisement (cf. | >> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). | >> | >> Knowing that: | >> (1) In common use-case, SAVI device is a L2 device | >> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection | >> | >> I am wondering whether or not fragmentation would not impact = strongly | >> SAVI specifications too: any fragmented NDP/SEND/DHCP message = could | >> not update correctly the Binding Table and so what would be the | >> consequences? | >> | >> I would appreciate comments from WG members, especially | >> implementors/manufacturers, about this. | >> | >> Thanks in advance for your replies. | >> | >> Best regards. | >> | >> JMC. | >> _______________________________________________ | >> savi mailing list | >> savi@ietf.org | >> https://www.ietf.org/mailman/listinfo/savi | >> _______________________________________________ | >> savi mailing list | >> savi@ietf.org | >> https://www.ietf.org/mailman/listinfo/savi | > | > | =20 | _______________________________________________ | savi mailing list | savi@ietf.org | https://www.ietf.org/mailman/listinfo/savi From nordmark@acm.org Wed Jun 22 06:50: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 069081F0C3B for ; Wed, 22 Jun 2011 06:50:04 -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 VwL7mNxFv-KW for ; Wed, 22 Jun 2011 06:50:03 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3C2951F0C35 for ; Wed, 22 Jun 2011 06:50:03 -0700 (PDT) Received: from [192.168.1.103] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p5MDnu6e028872 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 22 Jun 2011 06:49:58 -0700 Message-ID: <4E01F2FF.7030108@acm.org> Date: Wed, 22 Jun 2011 06:49:51 -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: SAVI Mailing List Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 22 Jun 2011 13:50:04 -0000 -------- Original Message -------- Subject: Re: [savi] Potential issue for all SAVI mechanisms? Date: Wed, 22 Jun 2011 06:39:15 -0700 From: Erik Nordmark To: marcelo bagnulo braun CC: savi@ietf.org On 6/21/11 10:26 PM, marcelo bagnulo braun wrote: > Right, the question is how comon is for legitimate users to send > NDP/DHCP/SEND fragmented packets? IS there any concrete real useful > situacion where this happens? The way I read RFC 4861's The size of an ND packet including the IP header is limited to the link MTU. When adding options to an ND packet, a node MUST NOT exceed the link MTU. is that ND packets should not be fragmented. But the spec doesn't have an explicit MUST NOT fragment. I haven't looked at the DHCP and SEND RFCs. > If not, maybe we could simply say that SAVI will ignore the fragmented > packets. > If yes, then it seems we may have a problem. I don't think we can just ignore them, since that would assume that the receivers would explicitly drop fragmented ND/DHCP/SEND packets, which they are not required to do. Can we always tell whether a packet, which might in theory have 2K of Destination options, is a ND/DHCP/SEND packet? Clearly not unless RFC 2460 requires that some bytes of the ULP (TCP, UDP, ICMP, etc) header is always in the first fragment. In practice it would be reasonable to expect that. But it seems to be a protocol change to IPv6 to require that senders must put the ULP header in the first fragment. Then the SAVI devices can assume and require that the known ULP is contained in the first fragment, thus they can determine whether a packet is ND/DHCP/SEND, and reject any such packets that include a fragment header. Erik > Regards, marcelo > > > El 22/06/11 06:35, Jun Bi escribió: >> In the Ethernet environment, the MTU is 1500, DHCP reply is not a >> large packet and it won't be fragmented. >> Maybe the packet size of RA is large and might be fragmented, but it >> is not processed in SAVI. >> >> thanks, >> Jun Bi >> >> -----原始邮件----- From: Joel M. Halpern >> Sent: Wednesday, June 22, 2011 8:17 AM >> To: Jun Bi >> Cc: Jean-Michel Combes ; SAVI Mailing List >> Subject: Re: [savi] Potential issue for all SAVI mechanisms? >> >> I do not think this is a sufficient answer. Whether the device is a >> switch or a router, reassembling or maintaining packet state across >> fragements is a non-trivial undertaking. >> >> I can imagine some kludges to get around this, but they have broader >> impact than just SAVI. (For example, rejecting first packets that do >> not have enough information to determine whether or not they are >> claiming to be RAs or DHCP replies.) >> >> Yours, >> Joel >> >> On 6/21/2011 9:56 AM, Jun Bi wrote: >>> Hi Jean-Michel, >>> >>> What we are talking about "savi switch" is a 2.5 layer switch (layer 2 >>> switch in data plan with layer 3-aware in controll/management plan). >>> So what I know from switch vendor is that the 2.5 layer switch chip or >>> the stronger CPU can handel it. >>> For example, the chip can recongnize the Protocol ID field of IP packets >>> to recongznie HDCP or NDP packets (even in fragments), >>> then copy them to switch CPU. The CPU can handle it. >>> >>> The SAVI switch has been really implmented and deployed, so I did really >>> see any problem in real network. >>> BTW, it seems that SAVI switch doesn't snoop and process RA packets for >>> binding, so maybe RA packet is different. >>> >>> thanks, >>> Jun Bi >>> >>> -----原始邮件----- From: Jean-Michel Combes >>> Sent: Tuesday, June 21, 2011 9:37 PM >>> To: SAVI Mailing List >>> Subject: [savi] Potential issue for all SAVI mechanisms? >>> >>> Hi, >>> >>> Maybe you already know that there is a discussion on v6ops/6man MLs >>> about RA Guard evasion (cf. >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). >>> One of the methods to perform this evasion is fragmentation: it seems >>> that a L2 device would not be able to re-assemble all the fragments >>> without an important extra-cost and so would not be able to determine >>> whether or not the message is a Router Advertisement (cf. >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). >>> >>> Knowing that: >>> (1) In common use-case, SAVI device is a L2 device >>> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection >>> >>> I am wondering whether or not fragmentation would not impact strongly >>> SAVI specifications too: any fragmented NDP/SEND/DHCP message could >>> not update correctly the Binding Table and so what would be the >>> consequences? >>> >>> I would appreciate comments from WG members, especially >>> implementors/manufacturers, about this. >>> >>> Thanks in advance for your replies. >>> >>> Best regards. >>> >>> JMC. >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jmh@joelhalpern.com Wed Jun 22 07:38: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 6342C21F84E0 for ; Wed, 22 Jun 2011 07:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.832 X-Spam-Level: X-Spam-Status: No, score=-101.832 tagged_above=-999 required=5 tests=[AWL=0.767, 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 9nSaP186hWhW for ; Wed, 22 Jun 2011 07:38: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 6045621F84A2 for ; Wed, 22 Jun 2011 07:38:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id C6DF032465FF; Wed, 22 Jun 2011 07:37:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 6946B3228BE3; Wed, 22 Jun 2011 07:37:31 -0700 (PDT) Message-ID: <4E01FE27.3030904@joelhalpern.com> Date: Wed, 22 Jun 2011 10:37:27 -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: marcelo bagnulo braun References: <4E013482.3080405@joelhalpern.com> <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> <4E01799E.7010109@joelhalpern.com> <4E017E70.9020907@it.uc3m.es> In-Reply-To: <4E017E70.9020907@it.uc3m.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: savi@ietf.org Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 22 Jun 2011 14:38:06 -0000 I considered whether we could "drop" short DHCP /RA packets. The problem is that the threat is precisely using fragmentation such that one can not identify the packet from one fragment. That is why I raised the straw man of declaring that first fragments for any packets in a SAVI network can not be that short. If we can drop the first fragment, we don't have to worry about what happens with the rest. But, that is a major change to the base IPv6 spec, and therefore is not, as far as I can tell, within the SAVI charter. Yours, Joel On 6/22/2011 1:32 AM, marcelo bagnulo braun wrote: > Right, for the SLAAC case we should differentiate two cases: > the case of RA and the case of NS and NA. > > The case of RA i think it is easy to solve. Only RA coming from trusted > ports should be processed and if you have an attacker there you have > bigger problems than the possibility of receiving fragmented RAs. The > current SLAAC draft doesn states that a SAVI device must only process RA > coming from trusted ports, but i think we should add text about this. > > The case of NA and NS is much more difficult to handle since they are > the main messages used by non trusted hosts/ports. > In this case, i still think that it would be importnat to understnad if > there is reasonable cases where a legitimate user needs to send > fragmented NA and NS. > > Regards, marcelo > > > > El 22/06/11 07:11, Joel M. Halpern escribió: >> You are missing the point. >> There is no rule that prevents a legitimate host from choosing to >> fragment the packets. >> Therefore, we can not simply drop short fragments. >> This means that a malicious device can choose to generate short >> fragments in order to mislead the filters. It can not mislead the >> filters about the IP address. But it can create false DHCP replies or >> RAs. >> >> The net effect would be to cause hosts to be unable to communicate, >> since they would be using improper addresses. >> >> yours, >> Joel >> >> On 6/22/2011 12:35 AM, Jun Bi wrote: >>> In the Ethernet environment, the MTU is 1500, DHCP reply is not a large >>> packet and it won't be fragmented. >>> Maybe the packet size of RA is large and might be fragmented, but it is >>> not processed in SAVI. >>> >>> thanks, >>> Jun Bi >>> >>> -----原始邮件----- From: Joel M. Halpern >>> Sent: Wednesday, June 22, 2011 8:17 AM >>> To: Jun Bi >>> Cc: Jean-Michel Combes ; SAVI Mailing List >>> Subject: Re: [savi] Potential issue for all SAVI mechanisms? >>> >>> I do not think this is a sufficient answer. Whether the device is a >>> switch or a router, reassembling or maintaining packet state across >>> fragements is a non-trivial undertaking. >>> >>> I can imagine some kludges to get around this, but they have broader >>> impact than just SAVI. (For example, rejecting first packets that do >>> not have enough information to determine whether or not they are >>> claiming to be RAs or DHCP replies.) >>> >>> Yours, >>> Joel >>> >>> On 6/21/2011 9:56 AM, Jun Bi wrote: >>>> Hi Jean-Michel, >>>> >>>> What we are talking about "savi switch" is a 2.5 layer switch (layer 2 >>>> switch in data plan with layer 3-aware in controll/management plan). >>>> So what I know from switch vendor is that the 2.5 layer switch chip or >>>> the stronger CPU can handel it. >>>> For example, the chip can recongnize the Protocol ID field of IP >>>> packets >>>> to recongznie HDCP or NDP packets (even in fragments), >>>> then copy them to switch CPU. The CPU can handle it. >>>> >>>> The SAVI switch has been really implmented and deployed, so I did >>>> really >>>> see any problem in real network. >>>> BTW, it seems that SAVI switch doesn't snoop and process RA packets for >>>> binding, so maybe RA packet is different. >>>> >>>> thanks, >>>> Jun Bi >>>> >>>> -----原始邮件----- From: Jean-Michel Combes >>>> Sent: Tuesday, June 21, 2011 9:37 PM >>>> To: SAVI Mailing List >>>> Subject: [savi] Potential issue for all SAVI mechanisms? >>>> >>>> Hi, >>>> >>>> Maybe you already know that there is a discussion on v6ops/6man MLs >>>> about RA Guard evasion (cf. >>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). >>>> One of the methods to perform this evasion is fragmentation: it seems >>>> that a L2 device would not be able to re-assemble all the fragments >>>> without an important extra-cost and so would not be able to determine >>>> whether or not the message is a Router Advertisement (cf. >>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). >>>> >>>> Knowing that: >>>> (1) In common use-case, SAVI device is a L2 device >>>> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection >>>> >>>> I am wondering whether or not fragmentation would not impact strongly >>>> SAVI specifications too: any fragmented NDP/SEND/DHCP message could >>>> not update correctly the Binding Table and so what would be the >>>> consequences? >>>> >>>> I would appreciate comments from WG members, especially >>>> implementors/manufacturers, about this. >>>> >>>> Thanks in advance for your replies. >>>> >>>> Best regards. >>>> >>>> JMC. >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>> >>> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From nordmark@sonic.net Wed Jun 22 06:39:37 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 2BAD821F849F for ; Wed, 22 Jun 2011 06:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 YEd+X4HuxPJd for ; Wed, 22 Jun 2011 06:39:36 -0700 (PDT) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by ietfa.amsl.com (Postfix) with ESMTP id 7E82321F849E for ; Wed, 22 Jun 2011 06:39:27 -0700 (PDT) Received: from [192.168.1.103] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p5MDdK0W010848 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 22 Jun 2011 06:39:23 -0700 Message-ID: <4E01F083.5030801@sonic.net> Date: Wed, 22 Jun 2011 06:39: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: marcelo bagnulo braun References: <4E013482.3080405@joelhalpern.com> <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> <4E017D0B.8090301@it.uc3m.es> In-Reply-To: <4E017D0B.8090301@it.uc3m.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 22 Jun 2011 08:18:01 -0700 Cc: savi@ietf.org Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 22 Jun 2011 13:39:37 -0000 On 6/21/11 10:26 PM, marcelo bagnulo braun wrote: > Right, the question is how comon is for legitimate users to send > NDP/DHCP/SEND fragmented packets? IS there any concrete real useful > situacion where this happens? The way I read RFC 4861's The size of an ND packet including the IP header is limited to the link MTU. When adding options to an ND packet, a node MUST NOT exceed the link MTU. is that ND packets should not be fragmented. But the spec doesn't have an explicit MUST NOT fragment. I haven't looked at the DHCP and SEND RFCs. > If not, maybe we could simply say that SAVI will ignore the fragmented > packets. > If yes, then it seems we may have a problem. I don't think we can just ignore them, since that would assume that the receivers would explicitly drop fragmented ND/DHCP/SEND packets, which they are not required to do. Can we always tell whether a packet, which might in theory have 2K of Destination options, is a ND/DHCP/SEND packet? Clearly not unless RFC 2460 requires that some bytes of the ULP (TCP, UDP, ICMP, etc) header is always in the first fragment. In practice it would be reasonable to expect that. But it seems to be a protocol change to IPv6 to require that senders must put the ULP header in the first fragment. Then the SAVI devices can assume and require that the known ULP is contained in the first fragment, thus they can determine whether a packet is ND/DHCP/SEND, and reject any such packets that include a fragment header. Erik > Regards, marcelo > > > El 22/06/11 06:35, Jun Bi escribió: >> In the Ethernet environment, the MTU is 1500, DHCP reply is not a >> large packet and it won't be fragmented. >> Maybe the packet size of RA is large and might be fragmented, but it >> is not processed in SAVI. >> >> thanks, >> Jun Bi >> >> -----原始邮件----- From: Joel M. Halpern >> Sent: Wednesday, June 22, 2011 8:17 AM >> To: Jun Bi >> Cc: Jean-Michel Combes ; SAVI Mailing List >> Subject: Re: [savi] Potential issue for all SAVI mechanisms? >> >> I do not think this is a sufficient answer. Whether the device is a >> switch or a router, reassembling or maintaining packet state across >> fragements is a non-trivial undertaking. >> >> I can imagine some kludges to get around this, but they have broader >> impact than just SAVI. (For example, rejecting first packets that do >> not have enough information to determine whether or not they are >> claiming to be RAs or DHCP replies.) >> >> Yours, >> Joel >> >> On 6/21/2011 9:56 AM, Jun Bi wrote: >>> Hi Jean-Michel, >>> >>> What we are talking about "savi switch" is a 2.5 layer switch (layer 2 >>> switch in data plan with layer 3-aware in controll/management plan). >>> So what I know from switch vendor is that the 2.5 layer switch chip or >>> the stronger CPU can handel it. >>> For example, the chip can recongnize the Protocol ID field of IP packets >>> to recongznie HDCP or NDP packets (even in fragments), >>> then copy them to switch CPU. The CPU can handle it. >>> >>> The SAVI switch has been really implmented and deployed, so I did really >>> see any problem in real network. >>> BTW, it seems that SAVI switch doesn't snoop and process RA packets for >>> binding, so maybe RA packet is different. >>> >>> thanks, >>> Jun Bi >>> >>> -----原始邮件----- From: Jean-Michel Combes >>> Sent: Tuesday, June 21, 2011 9:37 PM >>> To: SAVI Mailing List >>> Subject: [savi] Potential issue for all SAVI mechanisms? >>> >>> Hi, >>> >>> Maybe you already know that there is a discussion on v6ops/6man MLs >>> about RA Guard evasion (cf. >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). >>> One of the methods to perform this evasion is fragmentation: it seems >>> that a L2 device would not be able to re-assemble all the fragments >>> without an important extra-cost and so would not be able to determine >>> whether or not the message is a Router Advertisement (cf. >>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). >>> >>> Knowing that: >>> (1) In common use-case, SAVI device is a L2 device >>> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection >>> >>> I am wondering whether or not fragmentation would not impact strongly >>> SAVI specifications too: any fragmented NDP/SEND/DHCP message could >>> not update correctly the Binding Table and so what would be the >>> consequences? >>> >>> I would appreciate comments from WG members, especially >>> implementors/manufacturers, about this. >>> >>> Thanks in advance for your replies. >>> >>> Best regards. >>> >>> JMC. >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From elevyabe@cisco.com Fri Jun 24 01:37:55 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 B78A911E807B for ; Fri, 24 Jun 2011 01:37:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GZblYv-VlIUJ for ; Fri, 24 Jun 2011 01:37:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1D12311E8070 for ; Fri, 24 Jun 2011 01:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=elevyabe@cisco.com; l=7591; q=dns/txt; s=iport; t=1308904674; x=1310114274; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Li7rom2A+n/Qx/fQyoUEYPM0l30l+M0mik0hARBmKoQ=; b=PnWEEOi5hPTieU5kQB1Z6fJbzWABArhCh1UkQ2P8TsjiTWHp7h5wPltQ uIzHiPi+W0ySL7tB6LBrHr9tTUeV0223AoNYMzz0qqKIdQc8nXSWTJwo8 WmEgWs2dfQn/vWoZfnsRu7aUe2o3L9Vv0CyWDsY5APCvttlkWBkVYbzj1 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIAACVMBE6Q/khR/2dsb2JhbABEDoRJk0iPI3etDY0JkH6BK4F0gw4EkXuEaAmLIw X-IronPort-AV: E=Sophos;i="4.65,418,1304294400"; d="scan'208";a="97603496" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 24 Jun 2011 08:37:03 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5O8b3MT014192 for ; Fri, 24 Jun 2011 08:37:03 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 10:37:03 +0200 Received: from [144.254.53.117] ([144.254.53.117]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Jun 2011 10:37:03 +0200 Message-ID: <4E044CAF.6070503@cisco.com> Date: Fri, 24 Jun 2011 10:37:03 +0200 From: Eric Levy-Abegnoli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: savi@ietf.org References: <4E013482.3080405@joelhalpern.com> <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> <4E01799E.7010109@joelhalpern.com> <4E017E70.9020907@it.uc3m.es> <4E01FE27.3030904@joelhalpern.com> In-Reply-To: <4E01FE27.3030904@joelhalpern.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 24 Jun 2011 08:37:03.0863 (UTC) FILETIME=[E4BF1070:01CC3249] Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 24 Jun 2011 08:37:55 -0000 A couple of comments on the topic: - I don't see that it is in any way easier to poison the binding table using fragmented packets. So fragmented packets are more a problem for features like RA-guard ( that intend to block RA at the switch) or DHCP-guard (same for DHCP replies) when they are received from an untrusted device. However this is not within the scope of SAVI, is it? - Fragmented DHCP messages (or RAs) are causing the savi device a different problem: we might miss some bindings (if they are not in the first fragment). I don't see that as a big problem if these fragmented messages are anomalies (then the SAVI device will block traffic from the missed sources). It _is_ a problem however if the fragmented messages are not anomalies. And obviously, with DHCP at least, they might not be. - As far as the switch doing the "police" for hosts (RA-guard, etc.) the problem is very hard to solve on the switch, because it might be impossible to identify the Upper Layer (ICMP/RA, UDP/DHCP/REPLY) in the first fragment. A (smart) attacker would push the ULP into the second fragment. In addition, attackers use overlapping fragments, which most stacks accept today, and that allow to rewrite the ULP in the second fragment. So the switch simply cannot identify the real nature of such packets, unless it performs reassembly. Eric Le 22/06/2011 16:37, Joel M. Halpern a écrit : > I considered whether we could "drop" short DHCP /RA packets. > The problem is that the threat is precisely using fragmentation such > that one can not identify the packet from one fragment. > > That is why I raised the straw man of declaring that first fragments > for any packets in a SAVI network can not be that short. > > If we can drop the first fragment, we don't have to worry about what > happens with the rest. > But, that is a major change to the base IPv6 spec, and therefore is > not, as far as I can tell, within the SAVI charter. > > Yours, > Joel > > On 6/22/2011 1:32 AM, marcelo bagnulo braun wrote: >> Right, for the SLAAC case we should differentiate two cases: >> the case of RA and the case of NS and NA. >> >> The case of RA i think it is easy to solve. Only RA coming from trusted >> ports should be processed and if you have an attacker there you have >> bigger problems than the possibility of receiving fragmented RAs. The >> current SLAAC draft doesn states that a SAVI device must only process RA >> coming from trusted ports, but i think we should add text about this. >> >> The case of NA and NS is much more difficult to handle since they are >> the main messages used by non trusted hosts/ports. >> In this case, i still think that it would be importnat to understnad if >> there is reasonable cases where a legitimate user needs to send >> fragmented NA and NS. >> >> Regards, marcelo >> >> >> >> El 22/06/11 07:11, Joel M. Halpern escribió: >>> You are missing the point. >>> There is no rule that prevents a legitimate host from choosing to >>> fragment the packets. >>> Therefore, we can not simply drop short fragments. >>> This means that a malicious device can choose to generate short >>> fragments in order to mislead the filters. It can not mislead the >>> filters about the IP address. But it can create false DHCP replies or >>> RAs. >>> >>> The net effect would be to cause hosts to be unable to communicate, >>> since they would be using improper addresses. >>> >>> yours, >>> Joel >>> >>> On 6/22/2011 12:35 AM, Jun Bi wrote: >>>> In the Ethernet environment, the MTU is 1500, DHCP reply is not a >>>> large >>>> packet and it won't be fragmented. >>>> Maybe the packet size of RA is large and might be fragmented, but >>>> it is >>>> not processed in SAVI. >>>> >>>> thanks, >>>> Jun Bi >>>> >>>> -----原始邮件----- From: Joel M. Halpern >>>> Sent: Wednesday, June 22, 2011 8:17 AM >>>> To: Jun Bi >>>> Cc: Jean-Michel Combes ; SAVI Mailing List >>>> Subject: Re: [savi] Potential issue for all SAVI mechanisms? >>>> >>>> I do not think this is a sufficient answer. Whether the device is a >>>> switch or a router, reassembling or maintaining packet state across >>>> fragements is a non-trivial undertaking. >>>> >>>> I can imagine some kludges to get around this, but they have broader >>>> impact than just SAVI. (For example, rejecting first packets that do >>>> not have enough information to determine whether or not they are >>>> claiming to be RAs or DHCP replies.) >>>> >>>> Yours, >>>> Joel >>>> >>>> On 6/21/2011 9:56 AM, Jun Bi wrote: >>>>> Hi Jean-Michel, >>>>> >>>>> What we are talking about "savi switch" is a 2.5 layer switch >>>>> (layer 2 >>>>> switch in data plan with layer 3-aware in controll/management plan). >>>>> So what I know from switch vendor is that the 2.5 layer switch >>>>> chip or >>>>> the stronger CPU can handel it. >>>>> For example, the chip can recongnize the Protocol ID field of IP >>>>> packets >>>>> to recongznie HDCP or NDP packets (even in fragments), >>>>> then copy them to switch CPU. The CPU can handle it. >>>>> >>>>> The SAVI switch has been really implmented and deployed, so I did >>>>> really >>>>> see any problem in real network. >>>>> BTW, it seems that SAVI switch doesn't snoop and process RA >>>>> packets for >>>>> binding, so maybe RA packet is different. >>>>> >>>>> thanks, >>>>> Jun Bi >>>>> >>>>> -----原始邮件----- From: Jean-Michel Combes >>>>> Sent: Tuesday, June 21, 2011 9:37 PM >>>>> To: SAVI Mailing List >>>>> Subject: [savi] Potential issue for all SAVI mechanisms? >>>>> >>>>> Hi, >>>>> >>>>> Maybe you already know that there is a discussion on v6ops/6man MLs >>>>> about RA Guard evasion (cf. >>>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). >>>>> One of the methods to perform this evasion is fragmentation: it seems >>>>> that a L2 device would not be able to re-assemble all the fragments >>>>> without an important extra-cost and so would not be able to determine >>>>> whether or not the message is a Router Advertisement (cf. >>>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). >>>>> >>>>> Knowing that: >>>>> (1) In common use-case, SAVI device is a L2 device >>>>> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection >>>>> >>>>> I am wondering whether or not fragmentation would not impact strongly >>>>> SAVI specifications too: any fragmented NDP/SEND/DHCP message could >>>>> not update correctly the Binding Table and so what would be the >>>>> consequences? >>>>> >>>>> I would appreciate comments from WG members, especially >>>>> implementors/manufacturers, about this. >>>>> >>>>> Thanks in advance for your replies. >>>>> >>>>> Best regards. >>>>> >>>>> JMC. >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> _______________________________________________ >>>>> savi mailing list >>>>> savi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/savi >>>> >>>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From nordmark@sonic.net Fri Jun 24 07:26:59 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 68D3211E8076 for ; Fri, 24 Jun 2011 07:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 ViReVD+JW45V for ; Fri, 24 Jun 2011 07:26:58 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id 4A68C228020 for ; Fri, 24 Jun 2011 07:26:58 -0700 (PDT) Received: from [192.168.1.103] (64-103-25-233.cisco.com [64.103.25.233]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id p5OEQoFo003191 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 24 Jun 2011 07:26:54 -0700 Message-ID: <4E049EA6.7060106@sonic.net> Date: Fri, 24 Jun 2011 07:26:46 -0700 From: Erik Nordmark User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eric Levy-Abegnoli References: <4E013482.3080405@joelhalpern.com> <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> <4E01799E.7010109@joelhalpern.com> <4E017E70.9020907@it.uc3m.es> <4E01FE27.3030904@joelhalpern.com> <4E044CAF.6070503@cisco.com> In-Reply-To: <4E044CAF.6070503@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: savi@ietf.org Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 24 Jun 2011 14:26:59 -0000 On 6/24/11 1:37 AM, Eric Levy-Abegnoli wrote: > A couple of comments on the topic: > > - I don't see that it is in any way easier to poison the binding table > using fragmented packets. So fragmented packets are more a problem for > features like RA-guard ( that intend to block RA at the switch) or > DHCP-guard (same for DHCP replies) when they are received from an > untrusted device. However this is not within the scope of SAVI, is it? It isn't only the binding table that matters - it is also the Neighbor Caches on the attached nodes. If a SAVI device lets a NA or NS through, because it was fragmented in a way that made the SAVI device not see it as a NA or NS, then that can be used to corrupt the NC on the attached nodes. I guess that wouldn't be a SAVI problem; the node might think it has its IP address stolen, or send packets to the wrong MAC address, but the source addresses would still be enforced by SAVI based on its bindings. Thus worst SAVI case, for some node that fragments their NS or NA, is that the node's addresses would never be entered in the binding table and hence the node can not use the network. But that is the node's own problem - it can stop with such silly fragmentation. Erik > - Fragmented DHCP messages (or RAs) are causing the savi device a > different problem: we might miss some bindings (if they are not in the > first fragment). I don't see that as a big problem if these fragmented > messages are anomalies (then the SAVI device will block traffic from the > missed sources). It _is_ a problem however if the fragmented messages > are not anomalies. And obviously, with DHCP at least, they might not be. > > - As far as the switch doing the "police" for hosts (RA-guard, etc.) the > problem is very hard to solve on the switch, because it might be > impossible to identify the Upper Layer (ICMP/RA, UDP/DHCP/REPLY) in the > first fragment. A (smart) attacker would push the ULP into the second > fragment. In addition, attackers use overlapping fragments, which most > stacks accept today, and that allow to rewrite the ULP in the second > fragment. So the switch simply cannot identify the real nature of such > packets, unless it performs reassembly. > Eric > > Le 22/06/2011 16:37, Joel M. Halpern a écrit : >> I considered whether we could "drop" short DHCP /RA packets. >> The problem is that the threat is precisely using fragmentation such >> that one can not identify the packet from one fragment. >> >> That is why I raised the straw man of declaring that first fragments >> for any packets in a SAVI network can not be that short. >> >> If we can drop the first fragment, we don't have to worry about what >> happens with the rest. >> But, that is a major change to the base IPv6 spec, and therefore is >> not, as far as I can tell, within the SAVI charter. >> >> Yours, >> Joel >> >> On 6/22/2011 1:32 AM, marcelo bagnulo braun wrote: >>> Right, for the SLAAC case we should differentiate two cases: >>> the case of RA and the case of NS and NA. >>> >>> The case of RA i think it is easy to solve. Only RA coming from trusted >>> ports should be processed and if you have an attacker there you have >>> bigger problems than the possibility of receiving fragmented RAs. The >>> current SLAAC draft doesn states that a SAVI device must only process RA >>> coming from trusted ports, but i think we should add text about this. >>> >>> The case of NA and NS is much more difficult to handle since they are >>> the main messages used by non trusted hosts/ports. >>> In this case, i still think that it would be importnat to understnad if >>> there is reasonable cases where a legitimate user needs to send >>> fragmented NA and NS. >>> >>> Regards, marcelo >>> >>> >>> >>> El 22/06/11 07:11, Joel M. Halpern escribió: >>>> You are missing the point. >>>> There is no rule that prevents a legitimate host from choosing to >>>> fragment the packets. >>>> Therefore, we can not simply drop short fragments. >>>> This means that a malicious device can choose to generate short >>>> fragments in order to mislead the filters. It can not mislead the >>>> filters about the IP address. But it can create false DHCP replies or >>>> RAs. >>>> >>>> The net effect would be to cause hosts to be unable to communicate, >>>> since they would be using improper addresses. >>>> >>>> yours, >>>> Joel >>>> >>>> On 6/22/2011 12:35 AM, Jun Bi wrote: >>>>> In the Ethernet environment, the MTU is 1500, DHCP reply is not a >>>>> large >>>>> packet and it won't be fragmented. >>>>> Maybe the packet size of RA is large and might be fragmented, but >>>>> it is >>>>> not processed in SAVI. >>>>> >>>>> thanks, >>>>> Jun Bi >>>>> >>>>> -----原始邮件----- From: Joel M. Halpern >>>>> Sent: Wednesday, June 22, 2011 8:17 AM >>>>> To: Jun Bi >>>>> Cc: Jean-Michel Combes ; SAVI Mailing List >>>>> Subject: Re: [savi] Potential issue for all SAVI mechanisms? >>>>> >>>>> I do not think this is a sufficient answer. Whether the device is a >>>>> switch or a router, reassembling or maintaining packet state across >>>>> fragements is a non-trivial undertaking. >>>>> >>>>> I can imagine some kludges to get around this, but they have broader >>>>> impact than just SAVI. (For example, rejecting first packets that do >>>>> not have enough information to determine whether or not they are >>>>> claiming to be RAs or DHCP replies.) >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 6/21/2011 9:56 AM, Jun Bi wrote: >>>>>> Hi Jean-Michel, >>>>>> >>>>>> What we are talking about "savi switch" is a 2.5 layer switch >>>>>> (layer 2 >>>>>> switch in data plan with layer 3-aware in controll/management plan). >>>>>> So what I know from switch vendor is that the 2.5 layer switch >>>>>> chip or >>>>>> the stronger CPU can handel it. >>>>>> For example, the chip can recongnize the Protocol ID field of IP >>>>>> packets >>>>>> to recongznie HDCP or NDP packets (even in fragments), >>>>>> then copy them to switch CPU. The CPU can handle it. >>>>>> >>>>>> The SAVI switch has been really implmented and deployed, so I did >>>>>> really >>>>>> see any problem in real network. >>>>>> BTW, it seems that SAVI switch doesn't snoop and process RA >>>>>> packets for >>>>>> binding, so maybe RA packet is different. >>>>>> >>>>>> thanks, >>>>>> Jun Bi >>>>>> >>>>>> -----原始邮件----- From: Jean-Michel Combes >>>>>> Sent: Tuesday, June 21, 2011 9:37 PM >>>>>> To: SAVI Mailing List >>>>>> Subject: [savi] Potential issue for all SAVI mechanisms? >>>>>> >>>>>> Hi, >>>>>> >>>>>> Maybe you already know that there is a discussion on v6ops/6man MLs >>>>>> about RA Guard evasion (cf. >>>>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). >>>>>> One of the methods to perform this evasion is fragmentation: it seems >>>>>> that a L2 device would not be able to re-assemble all the fragments >>>>>> without an important extra-cost and so would not be able to determine >>>>>> whether or not the message is a Router Advertisement (cf. >>>>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). >>>>>> >>>>>> Knowing that: >>>>>> (1) In common use-case, SAVI device is a L2 device >>>>>> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection >>>>>> >>>>>> I am wondering whether or not fragmentation would not impact strongly >>>>>> SAVI specifications too: any fragmented NDP/SEND/DHCP message could >>>>>> not update correctly the Binding Table and so what would be the >>>>>> consequences? >>>>>> >>>>>> I would appreciate comments from WG members, especially >>>>>> implementors/manufacturers, about this. >>>>>> >>>>>> Thanks in advance for your replies. >>>>>> >>>>>> Best regards. >>>>>> >>>>>> JMC. >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jmh@joelhalpern.com Fri Jun 24 07:47: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 C6E1011E808C for ; Fri, 24 Jun 2011 07:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.139 X-Spam-Level: X-Spam-Status: No, score=-102.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 vLjtocDM2BNm for ; Fri, 24 Jun 2011 07:47:09 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id E4F5211E8076 for ; Fri, 24 Jun 2011 07:47:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id E1A0532466F2; Fri, 24 Jun 2011 07:46:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [172.17.114.244] (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id A52863246728; Fri, 24 Jun 2011 07:46:39 -0700 (PDT) Message-ID: <4E04A34B.2040909@joelhalpern.com> Date: Fri, 24 Jun 2011 10:46:35 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Eric Levy-Abegnoli References: <4E013482.3080405@joelhalpern.com> <70DEE8BFA1794CA9B6694032363C3460@junbiVAIOz138> <4E01799E.7010109@joelhalpern.com> <4E017E70.9020907@it.uc3m.es> <4E01FE27.3030904@joelhalpern.com> <4E044CAF.6070503@cisco.com> In-Reply-To: <4E044CAF.6070503@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: savi@ietf.org Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 24 Jun 2011 14:47:10 -0000 There is an interesting interaction between fake RAs / DHCPs and SAVI. As we have noted in other documents, RA-guard /DHCP-Guard complement SAVI, and help the SAVI mechanisms provide the right controls. The interesting effect therefore is that messages which slip past teh guards, and therefore are not recognized by SAVI, will mislead hosts without misleading the SAVI devices. This means that the honest hosts will be unable to communicate. That is probably an improvement over having them communicate using the wrong addresses, but it still causes difficulties. From conversation with Ran, and some analysis, it seems to me that the right answer to the problem is otuside of SAVI's scope. I think that the right answer is for hsots to ignore any such messages which are fragmented. Yours, Joel On 6/24/2011 4:37 AM, Eric Levy-Abegnoli wrote: > A couple of comments on the topic: > > - I don't see that it is in any way easier to poison the binding table > using fragmented packets. So fragmented packets are more a problem for > features like RA-guard ( that intend to block RA at the switch) or > DHCP-guard (same for DHCP replies) when they are received from an > untrusted device. However this is not within the scope of SAVI, is it? > > - Fragmented DHCP messages (or RAs) are causing the savi device a > different problem: we might miss some bindings (if they are not in the > first fragment). I don't see that as a big problem if these fragmented > messages are anomalies (then the SAVI device will block traffic from the > missed sources). It _is_ a problem however if the fragmented messages > are not anomalies. And obviously, with DHCP at least, they might not be. > > - As far as the switch doing the "police" for hosts (RA-guard, etc.) the > problem is very hard to solve on the switch, because it might be > impossible to identify the Upper Layer (ICMP/RA, UDP/DHCP/REPLY) in the > first fragment. A (smart) attacker would push the ULP into the second > fragment. In addition, attackers use overlapping fragments, which most > stacks accept today, and that allow to rewrite the ULP in the second > fragment. So the switch simply cannot identify the real nature of such > packets, unless it performs reassembly. > Eric > > Le 22/06/2011 16:37, Joel M. Halpern a écrit : >> I considered whether we could "drop" short DHCP /RA packets. >> The problem is that the threat is precisely using fragmentation such >> that one can not identify the packet from one fragment. >> >> That is why I raised the straw man of declaring that first fragments >> for any packets in a SAVI network can not be that short. >> >> If we can drop the first fragment, we don't have to worry about what >> happens with the rest. >> But, that is a major change to the base IPv6 spec, and therefore is >> not, as far as I can tell, within the SAVI charter. >> >> Yours, >> Joel >> >> On 6/22/2011 1:32 AM, marcelo bagnulo braun wrote: >>> Right, for the SLAAC case we should differentiate two cases: >>> the case of RA and the case of NS and NA. >>> >>> The case of RA i think it is easy to solve. Only RA coming from trusted >>> ports should be processed and if you have an attacker there you have >>> bigger problems than the possibility of receiving fragmented RAs. The >>> current SLAAC draft doesn states that a SAVI device must only process RA >>> coming from trusted ports, but i think we should add text about this. >>> >>> The case of NA and NS is much more difficult to handle since they are >>> the main messages used by non trusted hosts/ports. >>> In this case, i still think that it would be importnat to understnad if >>> there is reasonable cases where a legitimate user needs to send >>> fragmented NA and NS. >>> >>> Regards, marcelo >>> >>> >>> >>> El 22/06/11 07:11, Joel M. Halpern escribió: >>>> You are missing the point. >>>> There is no rule that prevents a legitimate host from choosing to >>>> fragment the packets. >>>> Therefore, we can not simply drop short fragments. >>>> This means that a malicious device can choose to generate short >>>> fragments in order to mislead the filters. It can not mislead the >>>> filters about the IP address. But it can create false DHCP replies or >>>> RAs. >>>> >>>> The net effect would be to cause hosts to be unable to communicate, >>>> since they would be using improper addresses. >>>> >>>> yours, >>>> Joel >>>> >>>> On 6/22/2011 12:35 AM, Jun Bi wrote: >>>>> In the Ethernet environment, the MTU is 1500, DHCP reply is not a >>>>> large >>>>> packet and it won't be fragmented. >>>>> Maybe the packet size of RA is large and might be fragmented, but >>>>> it is >>>>> not processed in SAVI. >>>>> >>>>> thanks, >>>>> Jun Bi >>>>> >>>>> -----原始邮件----- From: Joel M. Halpern >>>>> Sent: Wednesday, June 22, 2011 8:17 AM >>>>> To: Jun Bi >>>>> Cc: Jean-Michel Combes ; SAVI Mailing List >>>>> Subject: Re: [savi] Potential issue for all SAVI mechanisms? >>>>> >>>>> I do not think this is a sufficient answer. Whether the device is a >>>>> switch or a router, reassembling or maintaining packet state across >>>>> fragements is a non-trivial undertaking. >>>>> >>>>> I can imagine some kludges to get around this, but they have broader >>>>> impact than just SAVI. (For example, rejecting first packets that do >>>>> not have enough information to determine whether or not they are >>>>> claiming to be RAs or DHCP replies.) >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 6/21/2011 9:56 AM, Jun Bi wrote: >>>>>> Hi Jean-Michel, >>>>>> >>>>>> What we are talking about "savi switch" is a 2.5 layer switch >>>>>> (layer 2 >>>>>> switch in data plan with layer 3-aware in controll/management plan). >>>>>> So what I know from switch vendor is that the 2.5 layer switch >>>>>> chip or >>>>>> the stronger CPU can handel it. >>>>>> For example, the chip can recongnize the Protocol ID field of IP >>>>>> packets >>>>>> to recongznie HDCP or NDP packets (even in fragments), >>>>>> then copy them to switch CPU. The CPU can handle it. >>>>>> >>>>>> The SAVI switch has been really implmented and deployed, so I did >>>>>> really >>>>>> see any problem in real network. >>>>>> BTW, it seems that SAVI switch doesn't snoop and process RA >>>>>> packets for >>>>>> binding, so maybe RA packet is different. >>>>>> >>>>>> thanks, >>>>>> Jun Bi >>>>>> >>>>>> -----原始邮件----- From: Jean-Michel Combes >>>>>> Sent: Tuesday, June 21, 2011 9:37 PM >>>>>> To: SAVI Mailing List >>>>>> Subject: [savi] Potential issue for all SAVI mechanisms? >>>>>> >>>>>> Hi, >>>>>> >>>>>> Maybe you already know that there is a discussion on v6ops/6man MLs >>>>>> about RA Guard evasion (cf. >>>>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). >>>>>> One of the methods to perform this evasion is fragmentation: it seems >>>>>> that a L2 device would not be able to re-assemble all the fragments >>>>>> without an important extra-cost and so would not be able to determine >>>>>> whether or not the message is a Router Advertisement (cf. >>>>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). >>>>>> >>>>>> Knowing that: >>>>>> (1) In common use-case, SAVI device is a L2 device >>>>>> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection >>>>>> >>>>>> I am wondering whether or not fragmentation would not impact strongly >>>>>> SAVI specifications too: any fragmented NDP/SEND/DHCP message could >>>>>> not update correctly the Binding Table and so what would be the >>>>>> consequences? >>>>>> >>>>>> I would appreciate comments from WG members, especially >>>>>> implementors/manufacturers, about this. >>>>>> >>>>>> Thanks in advance for your replies. >>>>>> >>>>>> Best regards. >>>>>> >>>>>> JMC. >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>>> _______________________________________________ >>>>>> savi mailing list >>>>>> savi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/savi >>>>> >>>>> >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi From jeanmichel.combes@gmail.com Mon Jun 27 02:10: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 4FC9B21F866F for ; Mon, 27 Jun 2011 02:10:33 -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 ELvuv8l0PDF2 for ; Mon, 27 Jun 2011 02:10:32 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C873D21F866B for ; Mon, 27 Jun 2011 02:10:32 -0700 (PDT) Received: by gxk19 with SMTP id 19so2702224gxk.31 for ; Mon, 27 Jun 2011 02:10:32 -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:content-transfer-encoding; bh=jjUD4S44faekwj1nWHqauDk45AsFe4XLIaP/ICm/0nU=; b=g/CSP06hahGiQaBueKaWPPb/F0Y9hKQgzwMCIDDzhjOfqYdXIAZwa0fKa3CrURC9Pc 7/32a5EuyzI4jIeSiqzmlLdrBqJIr/SvHHRGHbj84+Bd1jGyvndc247lfz28utok5gf7 ChwT0yDZDOpBRt5wn9aQVFhmcTCbR+ImXmvGQ= 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:content-transfer-encoding; b=wxV2vSZmagDW5WKTDRD8PAe9f1u/2bJ8LEiOiLKth27oF+deZBqdrC5M1THMGziBpa ivcIqDwTSgOx2c31//OhTNrpHJ3avYdaY4G71wFWO9UEe5a3AM8KF79vlu3+ibUid3OU zc9ZYrjVooszZZ1gKtnXHZmkpuEbPG9YWq9t4= MIME-Version: 1.0 Received: by 10.150.48.28 with SMTP id v28mr5357810ybv.38.1309165831194; Mon, 27 Jun 2011 02:10:31 -0700 (PDT) Received: by 10.147.83.20 with HTTP; Mon, 27 Jun 2011 02:10:31 -0700 (PDT) In-Reply-To: <20110624183513.7035311E81A8@ietfa.amsl.com> References: <20110624183513.7035311E81A8@ietfa.amsl.com> Date: Mon, 27 Jun 2011 11:10:31 +0200 Message-ID: From: Jean-Michel Combes To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [savi] Fwd: Please help the Nomcom 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, 27 Jun 2011 09:10:33 -0000 FYI. JMC. ---------- Forwarded message ---------- From: NomCom Chair Date: 2011/6/24 Subject: Please help the Nomcom To: Working Group Chairs Hi WG chairs, =A0We have had a good response to the first call for volunteers but the rate at which new volunteers are coming in is slowing down. The Nomcom process is best served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. Where else would we find this wide spectrum if not in the WG mailing lists. I would really appreciate it if you can forward the message onto your working group mailing lists. The latest volunteer status and the second call for volunteers can be found at https://datatracker.ietf.org/ann/nomcom/2964/ Thanks in advance for your help. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com From jeanmichel.combes@gmail.com Tue Jun 28 10:27:00 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 B3B1121F86B8 for ; Tue, 28 Jun 2011 10:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.905 X-Spam-Level: X-Spam-Status: No, score=-101.905 tagged_above=-999 required=5 tests=[AWL=-1.695, BAYES_00=-2.599, CN_BODY_35=0.339, J_CHICKENPOX_29=0.6, MIME_CHARSET_FARAWAY=2.45, 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 LHDYa90c1CZY for ; Tue, 28 Jun 2011 10:26:59 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83CC111E80FD for ; Tue, 28 Jun 2011 10:26:59 -0700 (PDT) Received: by gya6 with SMTP id 6so224775gya.31 for ; Tue, 28 Jun 2011 10:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=9KF8rHNWOvzYppurYBoya5y560WIj3vNbnIErDRPIXY=; b=MNclO5mva8rdKHU+M+cByvTiZSiiYT704oWXsPkJILbMr3yFV4NBzMQJ98BqjC1vnJ PRNrFCpr7aTDPhbDQCJeNT/iwFn3AGbGuN2V4BfbALT2pBvaCV8vGDsB7h2LC1OakgTc vRPqXdFCvr3747/macbAAFcdwnpkR1YsjjOJg= MIME-Version: 1.0 Received: by 10.151.24.16 with SMTP id b16mr8997133ybj.195.1309282018338; Tue, 28 Jun 2011 10:26:58 -0700 (PDT) Received: by 10.147.182.9 with HTTP; Tue, 28 Jun 2011 10:26:58 -0700 (PDT) In-Reply-To: <4E01F2FF.7030108@acm.org> References: <4E01F2FF.7030108@acm.org> Date: Tue, 28 Jun 2011 19:26:58 +0200 Message-ID: From: Jean-Michel Combes To: Erik Nordmark Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Cc: SAVI Mailing List Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 28 Jun 2011 17:27:00 -0000 Hi, 2011/6/22 Erik Nordmark : > > > -------- Original Message -------- > Subject: Re: [savi] Potential issue for all SAVI mechanisms? > Date: Wed, 22 Jun 2011 06:39:15 -0700 > From: Erik Nordmark > To: marcelo bagnulo braun > CC: savi@ietf.org > > On 6/21/11 10:26 PM, marcelo bagnulo braun wrote: >> >> Right, the question is how comon is for legitimate users to send >> NDP/DHCP/SEND fragmented packets? IS there any concrete real useful >> situacion where this happens? > > The way I read RFC 4861's > The size of an ND packet including the IP header is limited to the > link MTU. When adding options to an ND packet, a node MUST NOT > exceed the link MTU. > is that ND packets should not be fragmented. But the spec doesn't have > an explicit MUST NOT fragment. This is a good point. > > I haven't looked at the DHCP and SEND RFCs. > >> If not, maybe we could simply say that SAVI will ignore the fragmented >> packets. >> If yes, then it seems we may have a problem. > > I don't think we can just ignore them, since that would assume that the > receivers would explicitly drop fragmented ND/DHCP/SEND packets, which > they are not required to do. > > Can we always tell whether a packet, which might in theory have 2K of > Destination options, is a ND/DHCP/SEND packet? Clearly not unless RFC > 2460 requires that some bytes of the ULP (TCP, UDP, ICMP, etc) header is > always in the first fragment. In practice it would be reasonable to > expect that. But it seems to be a protocol change to IPv6 to require > that senders must put the ULP header in the first fragment. Based on RFC 2460: (1) the Next Header value inside the Fragment header identifies the first header of the Fragmentable Part of the original packet (2) The Unfragmentable Part consists of the IPv6 header plus any extension headers that must be processed by nodes en route to the destination, that is, all headers up to and including the Routing header if present, else the Hop-by-Hop Options header if present, else no extension headers. (3) Extension header order is: IPv6 header, Hop-by-Hop Options header, Destination Options header, Routing header, Fragment header, Authentication header, Encapsulating Security Payload header, Destination Options header, upper-layer header So, as far as I can see, there are only 3 scenarios where the Next Header value inside the Fragment header is not ND(including SEND, as this is just ND options)/DHCP: (a) AH (b) ESP (c) Destination Option IMHO, ND/DHCP messages with such extension headers are not common ... > > Then the SAVI devices can assume and require that the known ULP is > contained in the first fragment, thus they can determine whether a > packet is ND/DHCP/SEND, and reject any such packets that include a > fragment header. Indeed, we could assume for each SAVI mechanism that: - if the Next Header value inside the Fragment header is ND/UDP(DHCP), the packet is processed - else the packet is dropped and the incident is logged As SAVI has a site/link scope, with the logs, IMHO, it should be easier for the SAVI admin to understand/solve the issue. Best regards. JMC. > > Erik > >> Regards, marcelo >> >> >> El 22/06/11 06:35, Jun Bi escribi=A8=AE: >>> >>> In the Ethernet environment, the MTU is 1500, DHCP reply is not a >>> large packet and it won't be fragmented. >>> Maybe the packet size of RA is large and might be fragmented, but it >>> is not processed in SAVI. >>> >>> thanks, >>> Jun Bi >>> >>> -----=D4=AD=CA=BC=D3=CA=BC=FE----- From: Joel M. Halpern >>> Sent: Wednesday, June 22, 2011 8:17 AM >>> To: Jun Bi >>> Cc: Jean-Michel Combes ; SAVI Mailing List >>> Subject: Re: [savi] Potential issue for all SAVI mechanisms? >>> >>> I do not think this is a sufficient answer. Whether the device is a >>> switch or a router, reassembling or maintaining packet state across >>> fragements is a non-trivial undertaking. >>> >>> I can imagine some kludges to get around this, but they have broader >>> impact than just SAVI. (For example, rejecting first packets that do >>> not have enough information to determine whether or not they are >>> claiming to be RAs or DHCP replies.) >>> >>> Yours, >>> Joel >>> >>> On 6/21/2011 9:56 AM, Jun Bi wrote: >>>> >>>> Hi Jean-Michel, >>>> >>>> What we are talking about "savi switch" is a 2.5 layer switch (layer 2 >>>> switch in data plan with layer 3-aware in controll/management plan). >>>> So what I know from switch vendor is that the 2.5 layer switch chip or >>>> the stronger CPU can handel it. >>>> For example, the chip can recongnize the Protocol ID field of IP packe= ts >>>> to recongznie HDCP or NDP packets (even in fragments), >>>> then copy them to switch CPU. The CPU can handle it. >>>> >>>> The SAVI switch has been really implmented and deployed, so I did real= ly >>>> see any problem in real network. >>>> BTW, it seems that SAVI switch doesn't snoop and process RA packets fo= r >>>> binding, so maybe RA packet is different. >>>> >>>> thanks, >>>> Jun Bi >>>> >>>> -----=D4=AD=CA=BC=D3=CA=BC=FE----- From: Jean-Michel Combes >>>> Sent: Tuesday, June 21, 2011 9:37 PM >>>> To: SAVI Mailing List >>>> Subject: [savi] Potential issue for all SAVI mechanisms? >>>> >>>> Hi, >>>> >>>> Maybe you already know that there is a discussion on v6ops/6man MLs >>>> about RA Guard evasion (cf. >>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14204.html). >>>> One of the methods to perform this evasion is fragmentation: it seems >>>> that a L2 device would not be able to re-assemble all the fragments >>>> without an important extra-cost and so would not be able to determine >>>> whether or not the message is a Router Advertisement (cf. >>>> http://www.ietf.org/mail-archive/web/ipv6/current/msg14240.html). >>>> >>>> Knowing that: >>>> (1) In common use-case, SAVI device is a L2 device >>>> (2) SAVI mechanisms are based on NDP/SEND/DHCP messages inspection >>>> >>>> I am wondering whether or not fragmentation would not impact strongly >>>> SAVI specifications too: any fragmented NDP/SEND/DHCP message could >>>> not update correctly the Binding Table and so what would be the >>>> consequences? >>>> >>>> I would appreciate comments from WG members, especially >>>> implementors/manufacturers, about this. >>>> >>>> Thanks in advance for your replies. >>>> >>>> Best regards. >>>> >>>> JMC. >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>>> _______________________________________________ >>>> savi mailing list >>>> savi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/savi >>> >>> _______________________________________________ >>> savi mailing list >>> savi@ietf.org >>> https://www.ietf.org/mailman/listinfo/savi >> >> _______________________________________________ >> savi mailing list >> savi@ietf.org >> https://www.ietf.org/mailman/listinfo/savi >> > > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi > From jmh@joelhalpern.com Tue Jun 28 10:40:11 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 CC36311E8139 for ; Tue, 28 Jun 2011 10:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.282 X-Spam-Level: X-Spam-Status: No, score=-102.282 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, J_CHICKENPOX_29=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 oHn2yBfj2KJZ for ; Tue, 28 Jun 2011 10:40:11 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1EC11E812F for ; Tue, 28 Jun 2011 10:40:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 64B3A32467BE; Tue, 28 Jun 2011 10:39:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.102] (pool-71-161-50-66.clppva.btas.verizon.net [71.161.50.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id A59C232463DD; Tue, 28 Jun 2011 10:39:40 -0700 (PDT) Message-ID: <4E0A11D8.5010300@joelhalpern.com> Date: Tue, 28 Jun 2011 13:39:36 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Jean-Michel Combes References: <4E01F2FF.7030108@acm.org> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: SAVI Mailing List Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 28 Jun 2011 17:40:11 -0000 I don't think this works. The question is not how often ND packets have that structure, but whether 1) Hosts will accept ND packets with that structure and 2) Other protocols will use that structure. If both of those are true, which they currently are, then a SAVI device can not detect an ND packet which is fragmented and hiding behind destination options. But, contrary to your resolution below, since other protocols use that construct, SAVI devices can not simply drop all packets that are fragmented and where the only visible next header is destination options (or AH, or ESP.) they would be dropping legitimate data packets. It does not matter whether any legitimate sender of ND messages would ever use that construct. As far as I can tell, the only path to sanity here is for the hosts not to accept such packets. And that is a matter for 6man, not for SAVI. We should simply document this as a residual threat. Yours, Joel On 6/28/2011 1:26 PM, Jean-Michel Combes wrote: > Based on RFC 2460: > (1) the Next Header value inside the Fragment header identifies the > first header of the Fragmentable Part of the original packet > (2) The Unfragmentable Part consists of the IPv6 header plus any > extension headers that must be processed by nodes en route to the > destination, that is, all headers up to and including the Routing > header if present, else the Hop-by-Hop Options header if present, else > no extension headers. > (3) Extension header order is: IPv6 header, Hop-by-Hop Options header, > Destination Options header, Routing header, Fragment header, > Authentication header, Encapsulating Security Payload header, > Destination Options header, upper-layer header > > So, as far as I can see, there are only 3 scenarios where the Next > Header value inside the Fragment header is not ND(including SEND, as > this is just ND options)/DHCP: > (a) AH > (b) ESP > (c) Destination Option > > IMHO, ND/DHCP messages with such extension headers are not common ... > > >> > >> > Then the SAVI devices can assume and require that the known ULP is >> > contained in the first fragment, thus they can determine whether a >> > packet is ND/DHCP/SEND, and reject any such packets that include a >> > fragment header. > Indeed, we could assume for each SAVI mechanism that: > - if the Next Header value inside the Fragment header is ND/UDP(DHCP), > the packet is processed > - else the packet is dropped and the incident is logged > > As SAVI has a site/link scope, with the logs, IMHO, it should be > easier for the SAVI admin to understand/solve the issue. > > Best regards. > > JMC. > > > From jeanmichel.combes@gmail.com Tue Jun 28 10:50:25 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 E306311E8135 for ; Tue, 28 Jun 2011 10:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.752 X-Spam-Level: X-Spam-Status: No, score=-102.752 tagged_above=-999 required=5 tests=[AWL=0.847, 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 ibd8ZpchSulW for ; Tue, 28 Jun 2011 10:50:25 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6285511E8102 for ; Tue, 28 Jun 2011 10:50:25 -0700 (PDT) Received: by yxp4 with SMTP id 4so253330yxp.31 for ; Tue, 28 Jun 2011 10:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BjJMShFLNJXMNqJcD1/PHQurEUDaLkKZ+YsEERRcGek=; b=sZEl4vgrkUk5kVg3KEMFw5u9b7XleFjtMPGbFhDSL3blrQ1dnrCC3v/jIHStu4P7g6 +TOj+g8P9xcouZUPG3mJ174U7blhGqUT1WlOR5M3/8A4uxxPS93vRgnD9RT8KXE/KFxL kXc+LMo8ZtpPT4BmiUtEUX8TTN9DZYe4vwu9U= MIME-Version: 1.0 Received: by 10.150.251.32 with SMTP id y32mr5985079ybh.138.1309283423867; Tue, 28 Jun 2011 10:50:23 -0700 (PDT) Received: by 10.147.182.9 with HTTP; Tue, 28 Jun 2011 10:50:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Jun 2011 19:50:23 +0200 Message-ID: From: Jean-Michel Combes To: SAVI Mailing List Content-Type: text/plain; charset=ISO-8859-1 Cc: int-ads@tools.ietf.org, Christian Vogt Subject: Re: [savi] Call for WG items for a potential rechartering 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, 28 Jun 2011 17:50:26 -0000 Folks, Based on received feedback, and in conjunction with ADs, SAVI chairs decided: (1) No SAVI meeting during the next IETF meeting in Quebec - Not enough manpower to launch a rechartering - Not enough potential items for a rechartering - All present issues regarding WG documents should be easily solved on the ML (2) Close the WG after the finalization of the RFC process for present WG documents but keep the mailing list alive - To get potential feedback from SAVI implementations/deployments - To allow a potential "rechartering" in the future (like what has been done in the past for the send/csi WGs or for ipsec/ipsecme WGs) for needed new mechanisms (e.g. MIB, etc.) Best regards. SAVI chairs. 2011/6/6 Jean-Michel Combes : > Folks, > > As promised during the last SAVI meeting in Prague, to prepare the > next IETF meeting, I would like to know whether WG members believe > there are still open issues the WG needs to work on or not. > > If so, please, reply to this email, providing a clear description of > the item and your contribution (i.e. Editor, Co-Author, Reviewer). For > each proposed item, at least three volunteers ready to review the > future document are requested. > > If you believe the WG has finished the work and can be closed, don't > hesitate to tell it too. > > The deadline to reply is 2011-06-20. > > Thanks in advance. > > Best regards. > > JMC. > From jeanmichel.combes@gmail.com Tue Jun 28 11:02: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 791C911E8131 for ; Tue, 28 Jun 2011 11:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_29=0.6, 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 8UOAcur+W1xP for ; Tue, 28 Jun 2011 11:02:41 -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 D42E811E808C for ; Tue, 28 Jun 2011 11:02:40 -0700 (PDT) Received: by gwb20 with SMTP id 20so226937gwb.31 for ; Tue, 28 Jun 2011 11:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=mjoaXjQAICIbbpnXGdx7FZ6/mA2b95q980YYu2HaTMs=; b=qoQNrPJkt1iDRuHkHFBp71f+mvhB/UpPL+b1i5xdsraNP6ExJ2L40DxfbVSscMIi4m bYYFU6HEjXAC2+WTPuGaTufsw9fUjBhLYccqolHpkTCLyE8X/b8JwrqNoNllO7YKA3u2 1PrAqhYIQs6cSZQvGguVVjqqT4Y5DNit1D0Oc= MIME-Version: 1.0 Received: by 10.146.59.36 with SMTP id h36mr2365028yaa.7.1309284160196; Tue, 28 Jun 2011 11:02:40 -0700 (PDT) Received: by 10.147.182.9 with HTTP; Tue, 28 Jun 2011 11:02:40 -0700 (PDT) In-Reply-To: <4E0A11D8.5010300@joelhalpern.com> References: <4E01F2FF.7030108@acm.org> <4E0A11D8.5010300@joelhalpern.com> Date: Tue, 28 Jun 2011 20:02:40 +0200 Message-ID: From: Jean-Michel Combes To: "Joel M. Halpern" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SAVI Mailing List Subject: Re: [savi] Potential issue for all SAVI mechanisms? 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, 28 Jun 2011 18:02:41 -0000 Hi Joel, 2011/6/28 Joel M. Halpern : > I don't think this works. > The question is not how often ND packets have that structure, but whether > 1) Hosts will accept ND packets with that structure > and > 2) Other protocols will use that structure. > > If both of those are true, which they currently are, then a SAVI device > can not detect an ND packet which is fragmented and hiding behind > destination options. > But, contrary to your resolution below, since other protocols use that > construct, SAVI devices can not simply drop all packets that are > fragmented and where the only visible next header is destination options > (or AH, or ESP.) =A0they would be dropping legitimate data packets. Yep, I missed this ... So, a new proposal: - if the Next Header value inside the Fragment header is ND/UDP(DHCP), the packet is processed by the SAVI device - if the Next Header value inside the Fragment header is not ND/UDP(DHCP) and there is a binding, the packet is processed by the SAVI device - else the packet is dropped and the incident is logged > > It does not matter whether any legitimate sender of ND messages would > ever use that construct. > > As far as I can tell, the only path to sanity here is for the hosts not > to accept such packets. > And that is a matter for 6man, not for SAVI. =A0We should simply document > this as a residual threat. IMHO, this is a matter for SAVI too, because, if the SAVI device is not able to process fragmented ND/DHCP packets from a node to correctly update the Binding Table, by default, any packet from this node will be dropped by the SAVI device even if hosts accept such packets. Cheers. JMC. > > Yours, > Joel > > > On 6/28/2011 1:26 PM, Jean-Michel Combes wrote: >> Based on RFC 2460: >> (1) the Next Header value inside the Fragment header identifies the >> first header of the Fragmentable Part of the original packet >> (2) The Unfragmentable Part consists of the IPv6 header plus any >> extension headers that must be processed by nodes en route to the >> destination, that is, all headers up to and including the Routing >> header if present, else the Hop-by-Hop Options header if present, else >> no extension headers. >> (3) Extension header order is: IPv6 header, Hop-by-Hop Options header, >> Destination Options header, Routing header, Fragment header, >> Authentication header, Encapsulating Security Payload header, >> Destination Options header, upper-layer header >> >> So, as far as I can see, there are only 3 scenarios where the Next >> Header value inside the Fragment header is not ND(including SEND, as >> this is just ND options)/DHCP: >> (a) AH >> (b) ESP >> (c) Destination Option >> >> IMHO, ND/DHCP messages with such extension headers are not common ... >> >> >>> > >>> > =A0Then the SAVI devices can assume and require that the known ULP is >>> > =A0contained in the first fragment, thus they can determine whether a >>> > =A0packet is ND/DHCP/SEND, and reject any such packets that include a >>> > =A0fragment header. >> Indeed, we could assume for each SAVI mechanism that: >> - if the Next Header value inside the Fragment header is ND/UDP(DHCP), >> the packet is processed >> - else the packet is dropped and the incident is logged >> >> As SAVI has a site/link scope, with the logs, IMHO, it should be >> easier for the SAVI admin to understand/solve the issue. >> >> Best regards. >> >> JMC. >> >> >> > From junbi@cernet.edu.cn Tue Jun 28 21:59:49 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 BA1DA21F863C for ; Tue, 28 Jun 2011 21:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.902 X-Spam-Level: X-Spam-Status: No, score=-99.902 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HAS_XAIMC=2.696, STOX_REPLY_TYPE=0.001, 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 ClOckmBNDdFv for ; Tue, 28 Jun 2011 21:59:49 -0700 (PDT) Received: from cernet.edu.cn (mail.cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with SMTP id EB40121F863A for ; Tue, 28 Jun 2011 21:59:46 -0700 (PDT) Received: from junbiVAIOz138([59.66.24.102]) by cernet.edu.cn(AIMC 3.2.0.0) with SMTP id jm74e0ace08; Wed, 29 Jun 2011 12:59:22 +0800 Message-ID: <48961EFFA8574BE9BA6E223E697913C1@junbiVAIOz138> From: "Jun Bi" To: "Jean-Michel Combes" , "SAVI Mailing List" References: In-Reply-To: Date: Wed, 29 Jun 2011 12:59:14 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original 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: MJyrmb0B Cc: int-ads@tools.ietf.org, Christian Vogt Subject: Re: [savi] Call for WG items for a potential rechartering 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, 29 Jun 2011 04:59:49 -0000 Hi WG chairs, What do you mean - To allow a potential "rechartering" in the future for needed new mechanisms (e.g. MIB, etc.). thanks, Jun Bi -----原始邮件----- From: Jean-Michel Combes Sent: Wednesday, June 29, 2011 1:50 AM To: SAVI Mailing List Cc: int-ads@tools.ietf.org ; Christian Vogt Subject: Re: [savi] Call for WG items for a potential rechartering Folks, Based on received feedback, and in conjunction with ADs, SAVI chairs decided: (1) No SAVI meeting during the next IETF meeting in Quebec - Not enough manpower to launch a rechartering - Not enough potential items for a rechartering - All present issues regarding WG documents should be easily solved on the ML (2) Close the WG after the finalization of the RFC process for present WG documents but keep the mailing list alive - To get potential feedback from SAVI implementations/deployments - To allow a potential "rechartering" in the future (like what has been done in the past for the send/csi WGs or for ipsec/ipsecme WGs) for needed new mechanisms (e.g. MIB, etc.) Best regards. SAVI chairs. 2011/6/6 Jean-Michel Combes : > Folks, > > As promised during the last SAVI meeting in Prague, to prepare the > next IETF meeting, I would like to know whether WG members believe > there are still open issues the WG needs to work on or not. > > If so, please, reply to this email, providing a clear description of > the item and your contribution (i.e. Editor, Co-Author, Reviewer). For > each proposed item, at least three volunteers ready to review the > future document are requested. > > If you believe the WG has finished the work and can be closed, don't > hesitate to tell it too. > > The deadline to reply is 2011-06-20. > > Thanks in advance. > > Best regards. > > JMC. > _______________________________________________ savi mailing list savi@ietf.org https://www.ietf.org/mailman/listinfo/savi From jeanmichel.combes@gmail.com Wed Jun 29 02:00: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 5574511E8081 for ; Wed, 29 Jun 2011 02:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.034 X-Spam-Level: X-Spam-Status: No, score=-103.034 tagged_above=-999 required=5 tests=[AWL=0.565, 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 GXtlWvOLP8qU for ; Wed, 29 Jun 2011 02:00:52 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB17F9E8024 for ; Wed, 29 Jun 2011 02:00:52 -0700 (PDT) Received: by yie30 with SMTP id 30so518206yie.31 for ; Wed, 29 Jun 2011 02:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=waBwaiY33xX2rHN0WufkgPP2xJo2eCEXTiogrpzdADo=; b=M0MwFBqi3I3n3H129WBL4o6vTEcfjttYp3bEr3FOP7eZj4j6A8JGU3QUvM4zqEPp4S Y6/5O8uhJIt+RgI8qpnl1eQ3LzRG5Lr/BqshtWmEEcOEJHAAAJNi9v/omF8Ej7Maptml Pcr/mOeXadZ3FbN3hYOma+Yglh3OXgEXbkkyw= MIME-Version: 1.0 Received: by 10.150.193.2 with SMTP id q2mr508286ybf.81.1309338051836; Wed, 29 Jun 2011 02:00:51 -0700 (PDT) Received: by 10.147.182.9 with HTTP; Wed, 29 Jun 2011 02:00:51 -0700 (PDT) In-Reply-To: <48961EFFA8574BE9BA6E223E697913C1@junbiVAIOz138> References: <48961EFFA8574BE9BA6E223E697913C1@junbiVAIOz138> Date: Wed, 29 Jun 2011 11:00:51 +0200 Message-ID: From: Jean-Michel Combes To: Jun Bi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: int-ads@tools.ietf.org, SAVI Mailing List , Christian Vogt Subject: Re: [savi] Call for WG items for a potential rechartering 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, 29 Jun 2011 09:00:53 -0000 Hi Jun, If there would be enough support in the future to work on new mechanisms and people would think these mechanisms should become IETF Standards, the ML will be the right place to initiate such a work. Now, don't forget that in parallel, there is also personal submission (i.e. AD shepherded/RFC Editor) for Experimental/Informational proposals. Is it clearer? Best regards. JMC. 2011/6/29 Jun Bi : > Hi WG chairs, > > What do you mean > > - To allow a potential "rechartering" in the future for needed new > mechanisms (e.g. MIB, etc.). > > thanks, > Jun Bi > > -----=E5=8E=9F=E5=A7=8B=E9=82=AE=E4=BB=B6----- From: Jean-Michel Combes > Sent: Wednesday, June 29, 2011 1:50 AM > To: SAVI Mailing List > Cc: int-ads@tools.ietf.org ; Christian Vogt > Subject: Re: [savi] Call for WG items for a potential rechartering > > Folks, > > Based on received feedback, and in conjunction with ADs, SAVI chairs > decided: > (1) No SAVI meeting during the next IETF meeting in Quebec > - Not enough manpower to launch a rechartering > - Not enough potential items for a rechartering > - All present issues regarding WG documents should be easily solved on th= e > ML > (2) Close the WG after the finalization of the RFC process for present > WG documents but keep the mailing list alive > - To get potential feedback from SAVI implementations/deployments > - To allow a potential "rechartering" in the future (like what has > been done in the past for the send/csi WGs or for ipsec/ipsecme WGs) > for needed new mechanisms (e.g. MIB, etc.) > > Best regards. > > SAVI chairs. > > 2011/6/6 Jean-Michel Combes : >> >> Folks, >> >> As promised during the last SAVI meeting in Prague, to prepare the >> next IETF meeting, I would like to know whether WG members believe >> there are still open issues the WG needs to work on or not. >> >> If so, please, reply to this email, providing a clear description of >> the item and your contribution (i.e. Editor, Co-Author, Reviewer). For >> each proposed item, at least three volunteers ready to review the >> future document are requested. >> >> If you believe the WG has finished the work and can be closed, don't >> hesitate to tell it too. >> >> The deadline to reply is 2011-06-20. >> >> Thanks in advance. >> >> Best regards. >> >> JMC. >> > _______________________________________________ > savi mailing list > savi@ietf.org > https://www.ietf.org/mailman/listinfo/savi >