From danny@tcb.net Sun May 2 18:27:14 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2E003A6845 for ; Sun, 2 May 2010 18:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.927 X-Spam-Level: X-Spam-Status: No, score=-100.927 tagged_above=-999 required=5 tests=[AWL=-0.928, BAYES_50=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOX6Jq2RX6vI for ; Sun, 2 May 2010 18:27:12 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 478E53A681A for ; Sun, 2 May 2010 18:27:12 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 896ED26866A; Sun, 2 May 2010 19:26:57 -0600 (MDT) Received: from [192.168.253.78] (209-252-239-15.ip.mcleodusa.net [209.252.239.15]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 02 May 2010 19:26:57 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=209.252.239.15; client-port=29661; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 From: Danny McPherson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 2 May 2010 19:26:56 -0600 Message-Id: <9054209B-FDBB-4601-813C-42406155F8EC@tcb.net> To: Jason Livingood Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Cc: opsec wg mailing list Subject: [OPSEC] LC comments on draft-oreirdan-mody-bot-remediation-08.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 01:27:14 -0000 Jason et al., Apologies for the late response, some comments below on the -08 spin of this draft. -danny --- General issues: - I'd recommend moving the Introduction and Problem Statement up at least above Terminology, if not to Section 1. - I think one of the points that should be made explicit in the introduction is something along these lines: "Broadband consumer attached end systems that are participating in bot-driven malicious activity is normally the result of compromise, and the subscribers themselves, consumers of services provided by their access service provider, are victims of this compromise. Service providers typically don't own, administer, or otherwise have remote access to subscriber end systems. As such, end-system level remediations that are ultimately necessary, and might normally be applicable as with enterprise or similar environments, are not usually viable options to bot remediation in consumer and residential access networks - at least until the consumer has been notified. These unique circumstances create a difficult predicament for service providers." - I suspect the discussion on benign or malicious bots (S 2.1) might well be informed by a slight variant on the concept, specifically, as we've seen evolve the past few years and as outlined by Gunter in "The Opt-In Botnet Generation". Of course, any more text here is probably just a distraction and will increase the noise level, but it could give consideration to this if others think it's useful. Additionally, it might be useful to provide a reference to a wide-spread application that might be non-maliciouls (e.g., SETI@home - http://setiathome.ssl.berkeley.edu/). From danny@tcb.net Sun May 2 20:56:58 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8E033A686E for ; Sun, 2 May 2010 20:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.918 X-Spam-Level: X-Spam-Status: No, score=-101.918 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZ3aRjpvjxGG for ; Sun, 2 May 2010 20:56:57 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 21C273A6358 for ; Sun, 2 May 2010 20:56:57 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id B109126866A; Sun, 2 May 2010 21:56:42 -0600 (MDT) Received: from [192.168.253.78] (209.252.239.15 [209.252.239.15]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 02 May 2010 21:56:42 -0600 (MDT) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=209.252.239.15; client-port=41336; client-dnsfail=209.252.239.15: name server failure; syn-fingerprint=65535:48:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Danny McPherson In-Reply-To: <9054209B-FDBB-4601-813C-42406155F8EC@tcb.net> Date: Sun, 2 May 2010 21:56:41 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <9054209B-FDBB-4601-813C-42406155F8EC@tcb.net> To: Jason Livingood X-Mailer: Apple Mail (2.1077) Cc: opsec wg mailing list Subject: Re: [OPSEC] LC comments on draft-oreirdan-mody-bot-remediation-08.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 03:56:58 -0000 On May 2, 2010, at 7:26 PM, Danny McPherson wrote: > > Jason et al., > Apologies for the late response, some comments below on > the -08 spin of this draft. Oops, Jason et al, I flushed my drafts queue prematurely when switching mail relays - this message wasn't fully baked. Most of the points stand, but I've got a more detailed analysis that I'll send when I get the time to complete that factors the whole draft after a re-read and another set of review comments. I.e., you're welcome to consider or disregard these comments, I intend to send more. Apologies for the confusion. -danny > > -danny > > --- > > General issues: > > - > I'd recommend moving the Introduction and Problem Statement > up at least above Terminology, if not to Section 1. > > - > I think one of the points that should be made explicit in the > introduction is something along these lines: > > "Broadband consumer attached end systems that are participating in > bot-driven malicious activity is normally the result of compromise, > and the subscribers themselves, consumers of services provided by > their access service provider, are victims of this compromise. Service > providers typically don't own, administer, or otherwise have remote > access to subscriber end systems. As such, end-system level remediations > that are ultimately necessary, and might normally be applicable as with > enterprise or similar environments, are not usually viable options to bot > remediation in consumer and residential access networks - at least until > the consumer has been notified. > > These unique circumstances create a difficult predicament for service > providers." > > > - > I suspect the discussion on benign or malicious bots (S 2.1) might > well be informed by a slight variant on the concept, specifically, > as we've seen evolve the past few years and as outlined by Gunter > in "The Opt-In Botnet Generation". Of course, any more text here > is probably just a distraction and will increase the noise level, > but it could give consideration to this if others think it's > useful. > > Additionally, it might be useful to provide a reference to a > wide-spread application that might be non-maliciouls (e.g., > SETI@home - http://setiathome.ssl.berkeley.edu/). > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From jtk@cymru.com Mon May 3 14:43:38 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A1928C2F1 for ; Mon, 3 May 2010 14:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.367 X-Spam-Level: * X-Spam-Status: No, score=1.367 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_60=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYngvLZTkhZD for ; Mon, 3 May 2010 14:43:37 -0700 (PDT) Received: from obelisk11.ord01.cymru.com (obelisk11.ord01.cymru.com [38.229.66.8]) by core3.amsl.com (Postfix) with ESMTP id A8D4528C2F9 for ; Mon, 3 May 2010 14:43:28 -0700 (PDT) Received: from t61p (vpn-21-33.svcs.iad01.cymru.com [192.168.21.33]) by obelisk11.ord01.cymru.com (Postfix) with ESMTP id 2AF28B00F4; Mon, 3 May 2010 21:43:13 +0000 (GMT) Date: Mon, 3 May 2010 16:43:11 -0500 From: John Kristoff To: Joel Jaeggli Message-ID: <20100503164311.505c3473@t61p> In-Reply-To: <4BCB49DB.8020104@bogus.com> References: <4BCB49DB.8020104@bogus.com> X-Mailer: Claws Mail Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] draft-ietf-opsec-ip-security-03 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 21:43:38 -0000 On Sun, 18 Apr 2010 11:05:15 -0700 Joel Jaeggli wrote: > if yu have anything to add it would be helpful if it were done this > week. Sorry about being a little late, but I finally got some time to finish reading through it. This is a substantial piece of work and kudos to Fernando for it. There is a lot of good stuff in here. I have some comments and some criticisms, but I think in the grand scheme of this work they are all relatively minor. One overriding comment is what will become of this document. The title says it is an assessment, but throughout there are recommendations, advice and suggestions for implementations and operators on how to mitigate the enumerated threats. It reads more like a BCP or standards track document to me. Trouble may arise if things get built to this document. At best, the predictability of the net would erode further if that happens. 1.1. Introduction Awkward or redundant wording "to the point that, to some extent,". 2. The Internet Protocol Another convenient characteristic is that with reduced complexity and minimum functionality comes, presumably, a limited set of security threats. This document could have been much larger with a different protocol. :-) 3.5. Identification (ID) "[Sanfilippo2998a] examined to determine" - grammar. 3.8. TTL While considered obsolete by the IP multicast operators, specific TTL values (e.g. 1, 16, 32, 64) have been used to control the scope of IP multicast packets. I don't know that this was officially documented in an RFC and I don't think it was ever officially obsoleted, but it was at least referred to as "difficult" and "complex" in RFC 2365. 3.11. Source Address BCP 84 is the new ingress filtering doc. 3.13.2. Issues with specific options Some of the address (i.e. bogon, nonsensical) concerns apply to the route options. Should loose/strict routing verify them and should an egress system look for leaks (i.e. bogons, private) being recorded? 4.1.1.2. Problems that arise from the length of the IP Identification field I'd note that in the networks of today, a dropped frame on the 1 Gb/s LAN is going to be very rare. Later in this section, spoofing is mentioned only in the last paragraph, but should probably be mentioned at the beginning of the prior one. 4.3. Addressing Maybe not appropriate in the end result document, but since you mentioned the Spoofer project elsewhere, you might also mention the bogon service Team Cymru offers. At the least, maybe make note that static lists of addresses are troublesome since they can and do change. John From fernando.gont.netbook.win@gmail.com Mon May 3 16:51:21 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3373A6D22 for ; Mon, 3 May 2010 16:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngz26wDYM4fk for ; Mon, 3 May 2010 16:51:20 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.217.172]) by core3.amsl.com (Postfix) with ESMTP id B89623A6CBE for ; Mon, 3 May 2010 16:51:20 -0700 (PDT) Received: by gxk20 with SMTP id 20so398743gxk.8 for ; Mon, 03 May 2010 16:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=j9hLNqsU0gp5NF3tLsanCXVu+cj8p/oWmQHYii8iy/0=; b=vl/vvPvBSA/2ufcI7A7orcGzBATdLfdgJZzJgi5YRdXtYTsVtfHnZOZlGEFdN3TBYR yROuZIz1SaPaCg3bWQxgJex7DK+fwqsNpvi/W8T6OZmk5IAVoL4amYIzNJm4/qpKxCUb rXyscjcdX2+dwa6ASS7rn6p+hMkqqxjWbPX10= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=yEBxXwoAvBAJi6eYjhURQ6W1wzsTKpeO05/LYe18UwH4lTatAkdUsC0mQRgRCoUGhE xua7b972JkeBgDYFc79NOKx6Fy7Y9gZRScoJLMRQ89X0QE0q99Uto7dQS86SkyNXRNai uIcfIOcab2lN2gLR1emuNyqZYRkbp5MAb6S60= Received: by 10.150.168.18 with SMTP id q18mr9995108ybe.326.1272930663843; Mon, 03 May 2010 16:51:03 -0700 (PDT) Received: from [192.168.0.157] (85-128-17-190.fibertel.com.ar [190.17.128.85]) by mx.google.com with ESMTPS id 16sm2876721gxk.9.2010.05.03.16.51.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 May 2010 16:51:02 -0700 (PDT) Sender: Fernando Gont Message-ID: <4BDF6159.6010409@gont.com.ar> Date: Mon, 03 May 2010 20:50:49 -0300 From: Fernando Gont User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: John Kristoff References: <4BCB49DB.8020104@bogus.com> <20100503164311.505c3473@t61p> In-Reply-To: <20100503164311.505c3473@t61p> X-Enigmail-Version: 0.96.0 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] draft-ietf-opsec-ip-security-03 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 May 2010 23:51:21 -0000 Hi, John, Thanks so much for your feedback! Meta-comment/question: May I address your comments as part of the (upcoming) IETF LC, or do you think I should address them before we ship the document? Comments in-line.... > Trouble may arise if things get built to this > document. At best, the predictability of the net would erode further > if that happens. Actually, I'd argue the opposite. Real-world implementations do not follow the RFCs, because they are outdated. So everybody has been doing what they think is "best" to mitigate the security implications of IP. This documents a lot of what implementers/operators have done, trying to point out what makes sense, and what doesn't. And tries to provide advice so that implementations converge to "something". > 1.1. Introduction > > Awkward or redundant wording "to the point that, to some extent,". Really? (sorry, English as second language here). > 2. The Internet Protocol > > Another convenient characteristic is that with reduced complexity and > minimum functionality comes, presumably, a limited set of security > threats. This document could have been much larger with a different > protocol. :-) (Yeah... wait for the v6 version ;-) ) BTW, any text I should add something to address this comment? > 3.8. TTL > > While considered obsolete by the IP multicast operators, specific TTL > values (e.g. 1, 16, 32, 64) have been used to control the scope of IP > multicast packets. Isn't this already mentioned in the I-D? See the text in Section 3.8: --- cut here ---- However, it can also be used to perform important functions such as: o Improving the security of applications that make use of the Internet Protocol (IP). o Limiting spread of packets. ---- cut here ---- > I don't know that this was officially documented > in an RFC and I don't think it was ever officially obsoleted, but it > was at least referred to as "difficult" and "complex" in RFC 2365. Should I add a small note on this "difficult and complex" thing, and a pointer to RFC 2365? > 3.11. Source Address > > BCP 84 is the new ingress filtering doc. Thanks! I will update it. > 3.13.2. Issues with specific options > > Some of the address (i.e. bogon, nonsensical) concerns apply to the > route options. Should loose/strict routing verify them and should an > egress system look for leaks (i.e. bogons, private) being recorded? I'd argue that if they are processed, they should probably verify these addresses. However, my take is that packets with route options should be dropped by default. Actually, I'll be adding a note (in response to feedback received off-list), that some ISP-grade routers simply ignore IP options. > 4.1.1.2. Problems that arise from the length of the IP Identification > field > > I'd note that in the networks of today, a dropped frame on the 1 Gb/s > LAN is going to be very rare. Where, exactly, should I make this note? (i.e., I miss the context) > Later in this section, spoofing is > mentioned only in the last paragraph, but should probably be > mentioned at the beginning of the prior one. Suggestions? > 4.3. Addressing > > Maybe not appropriate in the end result document, but since you > mentioned the Spoofer project elsewhere, you might also mention the > bogon service Team Cymru offers. At the least, maybe make note that > static lists of addresses are troublesome since they can and do > change. I can't believe I missed to mention it. :-( Will fix this, and add a ref to the Team Cymru site. Thanks for catching this one! Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From jtk@cymru.com Fri May 7 11:46:21 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F4743A684A for ; Fri, 7 May 2010 11:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.745 X-Spam-Level: X-Spam-Status: No, score=0.745 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulda978vC-nH for ; Fri, 7 May 2010 11:46:19 -0700 (PDT) Received: from obelisk11.ord01.cymru.com (obelisk11.ord01.cymru.com [38.229.66.8]) by core3.amsl.com (Postfix) with ESMTP id 301C03A6917 for ; Fri, 7 May 2010 11:45:57 -0700 (PDT) Received: from t61p (vpn-21-39.svcs.iad01.cymru.com [192.168.21.39]) by obelisk11.ord01.cymru.com (Postfix) with ESMTP id 8F515B00E4; Fri, 7 May 2010 18:45:43 +0000 (GMT) Date: Fri, 7 May 2010 13:45:42 -0500 From: John Kristoff To: Fernando Gont Message-ID: <20100507134542.6c638f81@t61p> In-Reply-To: <4BDF6159.6010409@gont.com.ar> References: <4BCB49DB.8020104@bogus.com> <20100503164311.505c3473@t61p> <4BDF6159.6010409@gont.com.ar> X-Mailer: Claws Mail Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] draft-ietf-opsec-ip-security-03 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2010 18:46:21 -0000 On Mon, 03 May 2010 20:50:49 -0300 Fernando Gont wrote: > Meta-comment/question: May I address your comments as part of the > (upcoming) IETF LC, or do you think I should address them before we > ship the document? Doesn't matter to me. > This documents a lot of what implementers/operators have done, trying > to point out what makes sense, and what doesn't. And tries to provide > advice so that implementations converge to "something". Which circles back to my overriding comment. Is this a standards track document or not? The assessment is good stuff, but advice is sometimes ambiguous about what the best approach is. > > Awkward or redundant wording "to the point that, to some extent,". > > Really? (sorry, English as second language here). Alternative sentence: However, the success of the protocols led to their early and lasting adoption in production environments, where the world's economy now depends on them. > > 2. The Internet Protocol > > > > Another convenient characteristic is that with reduced complexity > > and minimum functionality comes, presumably, a limited set of > > security threats. This document could have been much larger with a > > different protocol. :-) > > (Yeah... wait for the v6 version ;-) ) > > BTW, any text I should add something to address this comment? It might be more appropriate for the Introduction, but maybe something like: The limited functionality provided by IP and the flexibility available to independent system designers has bred both success and trouble. Success through an efficient and malleable infrastructure that has adapted to new innovations. Trouble from a loose set of guidelines on where and how to implement security services. > > 3.8. TTL > > > > While considered obsolete by the IP multicast operators, specific > > TTL values (e.g. 1, 16, 32, 64) have been used to control the scope > > of IP multicast packets. > > Isn't this already mentioned in the I-D? See the text in Section 3.8: Yes, sufficiently so. Just pointing out that not specifically in the way IP multicast had historically used the TTL for scoping. > > I don't know that this was officially documented > > in an RFC and I don't think it was ever officially obsoleted, but > > it was at least referred to as "difficult" and "complex" in RFC > > 2365. > > Should I add a small note on this "difficult and complex" thing, and a > pointer to RFC 2365? I don't think its necessary. In hindsight I was being pedantic. :-) > I'd argue that if they are processed, they should probably verify > these addresses. However, my take is that packets with route options > should be dropped by default. Actually, I'll be adding a note (in > response to feedback received off-list), that some ISP-grade routers > simply ignore IP options. Maybe they should be dropped, but if this is an advice document on all of IPv4, then I would recommend a note about verifying them if they are enabled. > > 4.1.1.2. Problems that arise from the length of the IP > > Identification field > > > > I'd note that in the networks of today, a dropped frame on the 1 > > Gb/s LAN is going to be very rare. > > Where, exactly, should I make this note? (i.e., I miss the context) Probably nowhere, just a comment. The whole section just didn't seem very realistic or practical the way it was written, especially when it started out by saying how the original specification was built for a different time. A 1000BASE-T link is specified to have less than one bit error in every 10 billion transmitted. From the other perspective, if someone is causing buffers to overflow such that packets are being dropped somewhere, that DDoS is likely the bigger problem than fragment ID collisions. > > Later in this section, spoofing is > > mentioned only in the last paragraph, but should probably be > > mentioned at the beginning of the prior one. > > Suggestions? Suggested paragraph (added 'source address spoofed' bit): An attacker could exploit this fact to intentionally cause a system to discard all or part of the fragmented traffic it gets, thus performing a Denial-of-Service attack. Such an attacker would simply establish a flow of source address spoofed fragments with different IP Identification numbers, to trash all or part of the IP Identification space. As a result, the receiving system would use the attacker's fragments for the reassembly of legitimate datagrams, leading to corrupted packets which would later (and hopefully) get dropped. John From joelja@bogus.com Sun May 9 22:12:41 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402813A6AEB for ; Sun, 9 May 2010 22:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.786 X-Spam-Level: X-Spam-Status: No, score=-0.786 tagged_above=-999 required=5 tests=[AWL=-0.787, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02UyxfDz0kXR for ; Sun, 9 May 2010 22:12:39 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id 3EEB73A6AE8 for ; Sun, 9 May 2010 22:12:39 -0700 (PDT) Received: from [192.168.1.151] (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o4A5CQiA033931 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Mon, 10 May 2010 05:12:27 GMT (envelope-from joelja@bogus.com) Message-ID: <4BE795BA.9080306@bogus.com> Date: Sun, 09 May 2010 22:12:26 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: "'opsec@ietf.org'" X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Mon, 10 May 2010 05:12:28 +0000 (UTC) Subject: [OPSEC] fyi: Fwd: opsec - New Meeting Session Request for IETF 78 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 05:12:41 -0000 -------- Original Message -------- Subject: opsec - New Meeting Session Request for IETF 78 Date: Sun, 9 May 2010 08:37:10 -0700 (PDT) From: IETF Meeting Session Request Tool To: session-request@ietf.org CC: dromasca@avaya.com, rbonica@juniper.net, joelja@bogus.com, jabley@ca.afilias.info A new meeting session request has just been submitted by Joel Jaeggli, a working group chair of opsec. --------------------------------------------------------- Working Group Name: opsec Area Name: Operations and Management Area Session Requester: Joel Jaeggli Number of Sessions: 1 Length of Session(s): 1.5 hours Number of Attendees: 25 Conflicts to Avoid: First Priority: opsawg Second Priority: opsawg opsarea Special Requests: --------------------------------------------------------- From root@core3.amsl.com Thu May 13 13:15:14 2010 Return-Path: X-Original-To: opsec@ietf.org Delivered-To: opsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0344D3A6989; Thu, 13 May 2010 13:15:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100513201508.0344D3A6989@core3.amsl.com> Date: Thu, 13 May 2010 13:15:04 -0700 (PDT) Cc: opsec@ietf.org Subject: [OPSEC] I-D Action:draft-ietf-opsec-efforts-12.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 20:15:14 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Security Best Practices Efforts and Documents Author(s) : C. Lonvick, D. Spak Filename : draft-ietf-opsec-efforts-12.txt Pages : 35 Date : 2010-05-13 This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-efforts-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-opsec-efforts-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-05-13131412.I-D@ietf.org> --NextPart-- From joelja@bogus.com Fri May 14 15:16:38 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5303A68DC for ; Fri, 14 May 2010 15:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.387 X-Spam-Level: X-Spam-Status: No, score=-1.387 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQ00ocI3ZKqm for ; Fri, 14 May 2010 15:16:37 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id C8B8B3A68F8 for ; Fri, 14 May 2010 15:16:37 -0700 (PDT) Received: from [192.103.16.172] ([192.103.16.172]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o4EMGR7i026427 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Fri, 14 May 2010 22:16:27 GMT (envelope-from joelja@bogus.com) Message-ID: <4BEDCB9B.1070507@bogus.com> Date: Fri, 14 May 2010 15:15:55 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "'opsec@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Fri, 14 May 2010 22:16:27 +0000 (UTC) Subject: [OPSEC] WG last call test... draft-ietf-opsec-igp-crypto-requirements-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 22:16:38 -0000 We accepted this document as a wg item on 1/25/10 The document received significant editorial review in the WG prior to acceptance. I think last call has a significant value in clarifying what remaining discussion and review remains to be done. at your convenience please review the document: http://tools.ietf.org/html/draft-ietf-opsec-igp-crypto-requirements-00 and if necessary respond with commments no later than Friday May 28 2010 (two week from today). Thanks joel From warren@kumari.net Fri May 14 19:00:42 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04EBB3A6920 for ; Fri, 14 May 2010 19:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibbxhEEAmIPL for ; Fri, 14 May 2010 19:00:41 -0700 (PDT) Received: from smtp.kumari.net (smtp.kumari.net [216.177.58.220]) by core3.amsl.com (Postfix) with ESMTP id 34BBA3A691B for ; Fri, 14 May 2010 19:00:41 -0700 (PDT) Received: from [192.168.0.216] (pool-71-114-38-199.washdc.dsl-w.verizon.net [71.114.38.199]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.kumari.net (Postfix) with ESMTPSA id 283902284482; Fri, 14 May 2010 21:57:45 -0400 (EDT) From: Warren Kumari To: joel jaeggli In-Reply-To: <4BEDCB9B.1070507@bogus.com> X-Mailer: iPad Mail (7B367) References: <4BEDCB9B.1070507@bogus.com> Message-Id: <34F988AD-C820-4623-8035-0EBCF0B54EDF@kumari.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (iPad Mail 7B367) Date: Fri, 14 May 2010 22:00:27 -0400 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] WG last call test... draft-ietf-opsec-igp-crypto-requirements-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 02:00:42 -0000 I had some really minor nits that I wrote down somewhere but seem to = have now misplaced. I support this as it is, if I happen to come across notes before the = deadline I'll forward em on, but if not it's all good.... W On May 14, 2010, at 6:15 PM, joel jaeggli wrote: > We accepted this document as a wg item on 1/25/10 >=20 > The document received significant editorial review in the WG prior to = acceptance. I think last call has a significant value in clarifying what = remaining discussion and review remains to be done. >=20 > at your convenience please review the document: >=20 > http://tools.ietf.org/html/draft-ietf-opsec-igp-crypto-requirements-00 >=20 > and if necessary respond with commments no later than Friday May 28 = 2010 (two week from today). >=20 > Thanks > joel >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From glen.kent@gmail.com Fri May 14 19:12:31 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06DB03A6856 for ; Fri, 14 May 2010 19:12:31 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99Y9UjmN0S5R for ; Fri, 14 May 2010 19:12:29 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by core3.amsl.com (Postfix) with ESMTP id A319A3A67B3 for ; Fri, 14 May 2010 19:12:29 -0700 (PDT) Received: by yxe12 with SMTP id 12so1597029yxe.32 for ; Fri, 14 May 2010 19:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=C6EcnAMVgyMhDQYjbHgT71vTQIbFFB69xkGIyNAvnrU=; b=sRFHBS8teUJO2poS56RF08Rt1nJditxfXlVZX6CdnUr8op4+XPZXuNmrqNomz43UCA ZJRPiRqx1/ZDCVTQuXw69j6h+0Ht51RLbrAqswAo/hp1m7QlmCXph9TC8xQ2MWPulDcJ 2+fu3EXdKlIaUXdnRr1pPmny/8nn5aeWxPN/g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=I9qXPSGvw5bT/FLKNx3Obpn66YxzE4OmFjg7b/IuhRUuUSK3Nk3GJf+SMz9ZuKzegF oOHbuvuKZwJgYzzlXGhf0iOz1fgXxkCYmgbOkC1JLZDwH7Gh0tb3VMl8HIqGzlb9oNbr n7JsvB36emJ3lSIiKGBrxhb9KABTYt+UjGjQM= MIME-Version: 1.0 Received: by 10.100.246.35 with SMTP id t35mr2553912anh.14.1273889537986; Fri, 14 May 2010 19:12:17 -0700 (PDT) Received: by 10.100.123.3 with HTTP; Fri, 14 May 2010 19:12:17 -0700 (PDT) In-Reply-To: <4BEDCB9B.1070507@bogus.com> References: <4BEDCB9B.1070507@bogus.com> Date: Sat, 15 May 2010 07:42:17 +0530 Message-ID: From: Glen Kent To: joel jaeggli , opsec wg mailing list Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [OPSEC] WG last call test... draft-ietf-opsec-igp-crypto-requirements-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 02:12:31 -0000 I support this work. Glen On Sat, May 15, 2010 at 3:45 AM, joel jaeggli wrote: > We accepted this document as a wg item on 1/25/10 > > The document received significant editorial review in the WG prior to > acceptance. I think last call has a significant value in clarifying what > remaining discussion and review remains to be done. > > at your convenience please review the document: > > http://tools.ietf.org/html/draft-ietf-opsec-igp-crypto-requirements-00 > > and if necessary respond with commments no later than Friday May 28 2010 > (two week from today). > > Thanks > joel > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From joelja@bogus.com Sat May 29 20:17:59 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38C253A69C7 for ; Sat, 29 May 2010 20:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Rq-A89cJ0UD for ; Sat, 29 May 2010 20:17:58 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id 57FE73A69A6 for ; Sat, 29 May 2010 20:17:58 -0700 (PDT) Received: from [192.168.1.137] (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o4U3Hkb5099843 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 30 May 2010 03:17:47 GMT (envelope-from joelja@bogus.com) Message-ID: <4C01D8D9.7050106@bogus.com> Date: Sat, 29 May 2010 20:17:45 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "'opsec@ietf.org'" References: <4BEDCB9B.1070507@bogus.com> In-Reply-To: <4BEDCB9B.1070507@bogus.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 30 May 2010 03:17:47 +0000 (UTC) Subject: Re: [OPSEC] WG last call test... draft-ietf-opsec-igp-crypto-requirements-00 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 03:17:59 -0000 Warren Kumari and Glen kept supported this work in it's current form. There were no objections. We will write up a document shepherd document and mover forward. joel On 2010-05-14 15:15, joel jaeggli wrote: > We accepted this document as a wg item on 1/25/10 > > The document received significant editorial review in the WG prior to > acceptance. I think last call has a significant value in clarifying what > remaining discussion and review remains to be done. > > at your convenience please review the document: > > http://tools.ietf.org/html/draft-ietf-opsec-igp-crypto-requirements-00 > > and if necessary respond with commments no later than Friday May 28 2010 > (two week from today). > > Thanks > joel > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From joelja@bogus.com Sat May 29 20:21:42 2010 Return-Path: X-Original-To: opsec@core3.amsl.com Delivered-To: opsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7997A3A6853 for ; Sat, 29 May 2010 20:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHgkNJQ2IlWI for ; Sat, 29 May 2010 20:21:41 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [147.28.0.81]) by core3.amsl.com (Postfix) with ESMTP id 637143A657C for ; Sat, 29 May 2010 20:21:41 -0700 (PDT) Received: from [192.168.1.137] (c-98-234-104-156.hsd1.ca.comcast.net [98.234.104.156]) (authenticated bits=0) by nagasaki.bogus.com (8.14.3/8.14.3) with ESMTP id o4U3LU72000208 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sun, 30 May 2010 03:21:30 GMT (envelope-from joelja@bogus.com) Message-ID: <4C01D9BA.5050709@bogus.com> Date: Sat, 29 May 2010 20:21:30 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "'opsec@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Sun, 30 May 2010 03:21:30 +0000 (UTC) Subject: [OPSEC] schedule prior to ietf 78... X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 May 2010 03:21:42 -0000 FYI, the schedule we're operating under related to this ietf meeting is as follows: # 2010-06-23 (Wednesday): Preliminary agenda published for comment. # 2010-06-28 (Monday): Working Group Chair approval for initial document (Version -00) submissions appreciated by 17:00 PDT (24:00 UTC). # 2010-07-02 (Friday): Final agenda to be published. # 2010-07-05 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PDT (24:00 UTC), upload using IETF ID Submission Tool. # 2010-07-12 (Monday): Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC), upload using IETF ID Submission Tool. # 2010-07-14 (Wednesday): Draft Working Group agendas due by 17:00 PDT (24:00 UTC), upload using IETF Meeting Materials Management Tool. # 2010-07-19 (Monday): Revised Working Group agendas due by 17:00 PDT (24:00 UTC), upload using IETF Meeting Materials Management Tool. # 2010-07-25 - 2010-07-30: 78th IETF Meeting in Maastricht, Netherlands.