From fred@cisco.com Sat Mar 3 16:22:31 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FC721F85D2 for ; Sat, 3 Mar 2012 16:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=4.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhiND8glKAOg for ; Sat, 3 Mar 2012 16:22:30 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8259D21F85FC for ; Sat, 3 Mar 2012 16:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=879; q=dns/txt; s=iport; t=1330820541; x=1332030141; h=from:subject:date:references:to:message-id:mime-version: content-transfer-encoding; bh=gCsVW8O4E/dtB0FuJ4ENwm15Zs1nlPVMM6wefEqtlEU=; b=RaDN0y7RAqWwpoOvN13eEdgzAtFy0PmKLnbvC1mgwmKyztd+8IvJI66Q 2UHAbV1Rr8mR9iqrClZ2TB6SDA/4RgV/xYrglv+Y03U61r0x2WyR53U7p wvTDLw8N0ilRdrvWsCqTDw+dhrEDi/lZM84DUhtG1c44qBPwaQi/zX5no s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAJK0Uk9Io8UY/2dsb2JhbABDtVWBfQEBAQMBEgEnPQcLHAMBAi9NAggZIodgBQugZQGWHY07gj9jBIhOjHCFYYoxgnI X-IronPort-AV: E=Sophos;i="4.73,527,1325462400"; d="scan'208";a="7046217" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 04 Mar 2012 00:22:16 +0000 Received: from Freds-Computer.local (tky-vpn-client-230-90.cisco.com [10.70.230.90]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q240MF4c012238 for ; Sun, 4 Mar 2012 00:22:16 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sun, 04 Mar 2012 09:22:16 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Sun, 04 Mar 2012 09:22:16 +0900 From: Fred Baker Date: Sun, 4 Mar 2012 09:22:03 +0900 References: <20120304000756.12624.59747.idtracker@ietfa.amsl.com> To: opsec@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [OPSEC] Fwd: New Version Notification for draft-baker-opsec-passive-ip-address-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 00:22:32 -0000 For your comment. http://tools.ietf.org/html/draft-baker-opsec-passive-ip-address > From: internet-drafts@ietf.org > Date: March 4, 2012 9:07:56 AM GMT+09:00 > To: fred@cisco.com > Cc: gvandeve@cisco.com > Subject: New Version Notification for = draft-baker-opsec-passive-ip-address-00.txt >=20 > A new version of I-D, draft-baker-opsec-passive-ip-address-00.txt has = been successfully submitted by Fred Baker and posted to the IETF = repository. >=20 > Filename: draft-baker-opsec-passive-ip-address > Revision: 00 > Title: Passive IP Addresses > Creation date: 2012-03-04 > WG ID: Individual Submission > Number of pages: 9 >=20 > Abstract: > This note suggests an approach to minimizing the attack surface of > the network elements - routers, switches, and middleware - of a > network. >=20 >=20 >=20 >=20 > The IETF Secretariat From ayourtch@cisco.com Mon Mar 5 03:06:52 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55B021F8726 for ; Mon, 5 Mar 2012 03:06:52 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpqYv1v+Z2S7 for ; Mon, 5 Mar 2012 03:06:52 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1E44C21F8700 for ; Mon, 5 Mar 2012 03:06:51 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q25B6lQH000488 for ; Mon, 5 Mar 2012 12:06:47 +0100 (CET) Received: from ams-ayourtch-8719.cisco.com (ams-ayourtch-8719.cisco.com [10.55.144.250]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q25B6j5M025186; Mon, 5 Mar 2012 12:06:45 +0100 (CET) Date: Mon, 5 Mar 2012 12:06:44 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx To: opsec@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mircea.pisica@bt.com, sasad@cisco.com Subject: [OPSEC] New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 11:06:53 -0000 Hi all, We will be very thankful for the review/comments on this draft and hope to present it in Paris. --a ---------- Forwarded message ---------- Date: Mon, 05 Mar 2012 03:04:14 -0800 From: internet-drafts@ietf.org To: ayourtch@cisco.com Cc: mircea.pisica@bt.com, sasad@cisco.com Subject: New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt A new version of I-D, draft-yourtchenko-opsec-humansafe-ipv6-00.txt has been successfully submitted by Andrew Yourtchenko and posted to the IETF repository. Filename: draft-yourtchenko-opsec-humansafe-ipv6 Revision: 00 Title: Human-safe IPv6: Cryptographic transformation of hostnames as a base for secure and manageable addressing Creation date: 2012-03-02 WG ID: Individual Submission Number of pages: 9 Abstract: Although the IPv6 address space within a single /64 subnet is very large, the typical distribution of the addresses in this space is very non-uniform. This non-uniformity, together with the dictionary- based DNS brute-force enumeration, allows practical remote mapping of the IPv6 addresses in these subnets. This document proposes a technique which can be used to decrease the exposure of the server subnets to trivial scanning. As a side effect, the proposed technique allows to drastically simplify the address management. The IETF Secretariat From gvandeve@cisco.com Mon Mar 5 03:42:59 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC2821F872F for ; Mon, 5 Mar 2012 03:42:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.508 X-Spam-Level: X-Spam-Status: No, score=-10.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dmoqu-H1IFIC for ; Mon, 5 Mar 2012 03:42:58 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6640F21F8723 for ; Mon, 5 Mar 2012 03:42:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=8696; q=dns/txt; s=iport; t=1330947774; x=1332157374; h=mime-version:subject:date:message-id:from:to:cc; bh=/XIYng+TcpokM47IF+o+jt/NkTfU6r2v1Hhsssq/65o=; b=dHGc2DYA10kRITf94zwuCp4rTD2AkAhmgxgK9dhEmjf4W6Y5I/MqI7oD UTPJ4hbvx4g2TpqupDwJtsYIDRLWgvsvPsNX58A07v7CDY6QictHGXw28 AGb2oGs7ktV36+AOx1h0Agm+JQNyiHIXVdVPyuy+obvCtBIYHP73Msp+L g=; X-IronPort-AV: E=Sophos;i="4.73,533,1325462400"; d="scan'208,217";a="67675551" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 05 Mar 2012 11:42:52 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q25BgqL4002896; Mon, 5 Mar 2012 11:42:52 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 12:42:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: CDDm CQ30 GzoY G2iW M8mu QqAi T7Gr T+34 V/um YQhh YU3Y ZVuK eeP3 eo8H fOIk f2yR; 3; bwBwAHMAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAcgBvAG4AQABiAG8AbgBpAGMAYQAuAG8AcgBnADsAdwBhAHIAcgBlAG4AQABrAHUAbQBhAHIAaQAuAG4AZQB0AA==; Sosha1_v1; 7; {368B8A20-F5A5-4286-AD5E-3E9F3477F9A7}; ZwB2AGEAbgBkAGUAdgBlAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 05 Mar 2012 11:42:46 GMT; SQBFAFQARgAgAE8AUABTAEUAQwAgAFcARwAgAEQAZQBsAGkAdgBlAHIAYQBiAGwAZQBzACAALQA= MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFAC5.191357EC" x-cr-puzzleid: {368B8A20-F5A5-4286-AD5E-3E9F3477F9A7} Content-class: urn:content-classes:message Date: Mon, 5 Mar 2012 12:42:46 +0100 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC50705C450@XMB-AMS-102.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF OPSEC WG Deliverables - Thread-Index: Acz6xRVqyic5K2OgTwKv5MdiUeWznQ== From: "Gunter Van de Velde (gvandeve)" To: X-OriginalArrivalTime: 05 Mar 2012 11:42:52.0735 (UTC) FILETIME=[19542CF0:01CCFAC5] Cc: warren@kumari.net, Ron Bonica Subject: [OPSEC] IETF OPSEC WG Deliverables - X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 11:42:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFAC5.191357EC Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear all, =20 In an effort to re-energize the OPSEC WG, we have decided to drop any WG item which has not been progressed or updated last 2 years, and at the same time they will also be dropped from the OPSEC WG charter. =20 Thus, if your draft is NOT updated by the deadline of 12 March 2012 according the deadline mentioned at https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 then it will be removed from the OPSEC charter. =20 It is a hard decision to take, however to keep the WG fresh and the deliverables relevant for this current time, we believe we have to take this action. =20 During IETF83 we will revise the charter with input from the WG. =20 In any case, please find here info if you have questions about OPSEC and its charter: =20 http://tools.ietf.org/wg/opsec/ =20 https://datatracker.ietf.org/wg/opsec/charter/ =20 =20 Warren & Gunter =20 ------_=_NextPart_001_01CCFAC5.191357EC Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear = all,

 

In an effort to re-energize = the OPSEC WG, we have decided to drop any WG item which has not been progressed or updated last 2 years, and at the same time they will also be dropped = from the OPSEC WG charter.

 

Thus, if your draft is NOT = updated by the deadline of 12 March 2012 according the deadline mentioned at = https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 then it will be removed from the OPSEC = charter.

 

It is a hard decision to = take, however to keep the WG fresh and the deliverables relevant for this current = time, we believe we have to take this action.

 

During IETF83 we will revise = the charter with input from the WG.

 

In any case, please find here = info if you have questions about OPSEC and its charter:

 

http://tools.ietf.org/wg/opsec/

https://datatracker.ietf.org/wg/opsec/charter/

 

Warren & Gunter

 

------_=_NextPart_001_01CCFAC5.191357EC-- From gvandeve@cisco.com Mon Mar 5 03:46:22 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4894521F8638 for ; Mon, 5 Mar 2012 03:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.516 X-Spam-Level: X-Spam-Status: No, score=-10.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekyFbwkYzJAS for ; Mon, 5 Mar 2012 03:46:21 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 178DA21F8683 for ; Mon, 5 Mar 2012 03:46:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=5939; q=dns/txt; s=iport; t=1330947979; x=1332157579; h=mime-version:subject:date:message-id:from:to:cc; bh=rlTASQs23hA3qbHCQsO5O2peOekJo63wa+QtzdI0Wbk=; b=g8uHtsYOKL+O/UbHE8afpuuQJ/OswuXw0zxfhhMHNL0odwflpZiVyiwC rQFRSPBxyz062+ZmEC6gt2IXUZFdip6H90O9i2WrGD63/FwxCTR7KWoKa Rk5iCW7y5kkapO8sX899Ef120Uh5NHD/Z2H3faY0ydnWDD0825jFK7qQe k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMFANumVE+Q/khL/2dsb2JhbABDgkWpG4hpgQeBfwEEEgEJARADSRIBKgYYB1cBBBsah2WZYgGePo07gj9jBKVQgmQ X-IronPort-AV: E=Sophos;i="4.73,533,1325462400"; d="scan'208,217";a="131325886" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2012 11:46:18 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q25BkKlg003710; Mon, 5 Mar 2012 11:46:20 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 12:46:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFAC5.94BF5A10" Date: Mon, 5 Mar 2012 12:46:19 +0100 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC50705C45C@XMB-AMS-102.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Upcoming IETF OPSEC Meeting - Call for agenda items Thread-Index: Acz6xZR1BrF5SJ+mR/ChwoWF0ep7yQ== From: "Gunter Van de Velde (gvandeve)" To: X-OriginalArrivalTime: 05 Mar 2012 11:46:20.0222 (UTC) FILETIME=[95002DE0:01CCFAC5] Cc: warren@kumari.net Subject: [OPSEC] Upcoming IETF OPSEC Meeting - Call for agenda items X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 11:46:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFAC5.94BF5A10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear All, =20 We have planned a 60 minutes OPSEC meeting at upcoming IETF83 meeting Paris. =20 If you desire speaking time for your drafts, then please let and Warren know. =20 Kind Regards, =20 Gunter & Warren ------_=_NextPart_001_01CCFAC5.94BF5A10 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dear All,

 

We have planned a 60 minutes = OPSEC meeting at upcoming IETF83 meeting Paris.

 

If you desire speaking time for = your drafts, then please let and Warren know.

 

Kind = Regards,

 

Gunter & = Warren

------_=_NextPart_001_01CCFAC5.94BF5A10-- From gvandeve@cisco.com Mon Mar 5 03:48:26 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F94321F8730 for ; Mon, 5 Mar 2012 03:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.523 X-Spam-Level: X-Spam-Status: No, score=-10.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDsT2fZkYf2Y for ; Mon, 5 Mar 2012 03:48:25 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id E9E2C21F872D for ; Mon, 5 Mar 2012 03:48:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=9221; q=dns/txt; s=iport; t=1330948103; x=1332157703; h=mime-version:subject:date:message-id:from:to:cc; bh=Wy745R1wQfpr4KJAZaegsdEqdLen5BcTWKZm9ZSngKU=; b=NcL4raCTtu+sfht7NMY7dCoM11Je8CzeDPHT/s7MSoDAEZM1F8QDamzx a8dZdu/q3xXmmBAEOOtQHY0Gjk503w9cBbYPsGTMeAvxlR74Xuhp0mfYa QZZGTtHSnDloSVfxZTZFQuPGtJKsLLa0bURtfXwsl9lZHIxe5mQXjj2IH s=; X-IronPort-AV: E=Sophos;i="4.73,533,1325462400"; d="scan'208,217";a="131326109" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 05 Mar 2012 11:48:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q25BmOnD031809; Mon, 5 Mar 2012 11:48:24 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 12:48:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFAC5.DE8BE1C0" Date: Mon, 5 Mar 2012 12:48:23 +0100 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC50705C460@XMB-AMS-102.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF OPSEC WG Deliverables - WG Deliverables clean-up plan Thread-Index: Acz6xRVqyic5K2OgTwKv5MdiUeWznQAAKIbA From: "Gunter Van de Velde (gvandeve)" To: X-OriginalArrivalTime: 05 Mar 2012 11:48:24.0039 (UTC) FILETIME=[DECD2770:01CCFAC5] Cc: warren@kumari.net, Ron Bonica Subject: [OPSEC] IETF OPSEC WG Deliverables - WG Deliverables clean-up plan X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 11:48:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFAC5.DE8BE1C0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Send was quicker as the completing the title =20 =20 Dear all, =20 In an effort to re-energize the OPSEC WG, we have decided to drop any WG item which has not been progressed or updated last 2 years, and at the same time they will also be dropped from the OPSEC WG charter. =20 Thus, if your draft is NOT updated by the deadline of 12 March 2012 according the deadline mentioned at https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 then it will be removed from the OPSEC charter. =20 It is a hard decision to take, however to keep the WG fresh and the deliverables relevant for this current time, we believe we have to take this action. =20 During IETF83 we will revise the charter with input from the WG. =20 In any case, please find here info if you have questions about OPSEC and its charter: =20 http://tools.ietf.org/wg/opsec/ =20 https://datatracker.ietf.org/wg/opsec/charter/ =20 =20 Warren & Gunter =20 ------_=_NextPart_001_01CCFAC5.DE8BE1C0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Send was = quicker as the completing the title

 

 

Dear = all,

 

In an effort to re-energize = the OPSEC WG, we have decided to drop any WG item which has not been progressed or updated last 2 years, and at the same time they will also be dropped = from the OPSEC WG charter.

 

Thus, if your draft is NOT = updated by the deadline of 12 March 2012 according the deadline mentioned at = https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83 then it will be removed from the OPSEC = charter.

 

It is a hard decision to = take, however to keep the WG fresh and the deliverables relevant for this current = time, we believe we have to take this action.

 

During IETF83 we will revise = the charter with input from the WG.

 

In any case, please find here = info if you have questions about OPSEC and its charter:

 

http://tools.ietf.org/wg/opsec/

https://datatracker.ietf.org/wg/opsec/charter/

 

Warren & Gunter

 

------_=_NextPart_001_01CCFAC5.DE8BE1C0-- From fernando.gont.netbook.win@gmail.com Mon Mar 5 22:17:36 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B777E21E806E for ; Mon, 5 Mar 2012 22:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCXvhzdcoQzj for ; Mon, 5 Mar 2012 22:17:36 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E960921E8045 for ; Mon, 5 Mar 2012 22:17:35 -0800 (PST) Received: by ggmi1 with SMTP id i1so2311842ggm.31 for ; Mon, 05 Mar 2012 22:17:34 -0800 (PST) Received-SPF: pass (google.com: domain of fernando.gont.netbook.win@gmail.com designates 10.236.175.36 as permitted sender) client-ip=10.236.175.36; Authentication-Results: mr.google.com; spf=pass (google.com: domain of fernando.gont.netbook.win@gmail.com designates 10.236.175.36 as permitted sender) smtp.mail=fernando.gont.netbook.win@gmail.com; dkim=pass header.i=fernando.gont.netbook.win@gmail.com Received: from mr.google.com ([10.236.175.36]) by 10.236.175.36 with SMTP id y24mr30800013yhl.64.1331014654530 (num_hops = 1); Mon, 05 Mar 2012 22:17:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=uXTBmp2SyFqDF9bsQ7M34KbKH15fDrfl/fhxvwXCLz0=; b=LlxbhK+b0y2sNwSKFOiD/8++yahrNhuifLcY4e+Ek2GglQiFvcYhQfDpxpyXBvNNYI IXQTACG5yz6CCVMePJ6cRe+1ubr8vXj/tFmQv6Egqn8yU1aIuLPC3iYIFoOEOKwukRsJ 1XbpdOBXpkUCSIadIBv38H3fFSsjQ6U+B6hK0dGSAPFZistzbRevw8eC0or917luADhf FpoA2smrJPauCg/SrMq4J3K0dp0FJQLh5X8s5NgvXui2/m2zRJcfh9ZZoRxXE6Fgd32d XMhW1Oia3tDs7KAEU6PpxCNbgnns81VpGNWcvgM4fXYkPt+Gm3gJJhSi63xMtdKIRIyW l4rQ== Received: by 10.236.175.36 with SMTP id y24mr24297452yhl.64.1331014654485; Mon, 05 Mar 2012 22:17:34 -0800 (PST) Received: from [192.168.123.102] ([186.134.8.162]) by mx.google.com with ESMTPS id o6sm7682633ank.2.2012.03.05.22.17.31 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 22:17:33 -0800 (PST) Sender: Fernando Gont Message-ID: <4F55ABF9.1090805@gont.com.ar> Date: Tue, 06 Mar 2012 03:17:29 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <5C99EC8C99D9BB45AC51D20DC2AD2DC50705C450@XMB-AMS-102.cisco.com> In-Reply-To: <5C99EC8C99D9BB45AC51D20DC2AD2DC50705C450@XMB-AMS-102.cisco.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, warren@kumari.net, Ron Bonica Subject: Re: [OPSEC] IETF OPSEC WG Deliverables - X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:17:36 -0000 Folks, What are the documents that are wg items, and that have not been updated recently? Thanks, Fernando On 03/05/2012 08:42 AM, Gunter Van de Velde (gvandeve) wrote: > Dear all, > > > > In an effort to re-energize the OPSEC WG, we have decided to drop any WG > item which has not been progressed or updated last 2 years, and at the > same time they will also be dropped from the OPSEC WG charter. > > > > Thus, if your draft is NOT updated by the deadline of 12 March 2012 > according the deadline mentioned at > https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83then it will > be removed from the OPSEC charter. > > > > It is a hard decision to take, however to keep the WG fresh and the > deliverables relevant for this current time, we believe we have to take > this action. > > > > During IETF83 we will revise the charter with input from the WG. > > > > In any case, please find here info if you have questions about OPSEC and > its charter: > > > > http://tools.ietf.org/wg/opsec/ > > https://datatracker.ietf.org/wg/opsec/charter/ > > > > Warren & Gunter > > > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fernando.gont.netbook.win@gmail.com Mon Mar 5 22:41:45 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CE021E8045 for ; Mon, 5 Mar 2012 22:41:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u40U5lxIxLFK for ; Mon, 5 Mar 2012 22:41:44 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 36E9621E8024 for ; Mon, 5 Mar 2012 22:41:44 -0800 (PST) Received: by ggmi1 with SMTP id i1so2316424ggm.31 for ; Mon, 05 Mar 2012 22:41:43 -0800 (PST) Received-SPF: pass (google.com: domain of fernando.gont.netbook.win@gmail.com designates 10.236.125.130 as permitted sender) client-ip=10.236.125.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of fernando.gont.netbook.win@gmail.com designates 10.236.125.130 as permitted sender) smtp.mail=fernando.gont.netbook.win@gmail.com; dkim=pass header.i=fernando.gont.netbook.win@gmail.com Received: from mr.google.com ([10.236.125.130]) by 10.236.125.130 with SMTP id z2mr30693053yhh.94.1331016103942 (num_hops = 1); Mon, 05 Mar 2012 22:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=A9tO9ad1mAeRxC6jSprbjtByB4OZG8f72/iXxg/QwkA=; b=JrpbGLmkdip9A0rDzlXSvMqw3Or4AxvehXGm3xgOScj9qtn4Ub1MgnpJuqjD+Mt4JU 4a/IiOYSE641VHSnJuA+ulUzMz+OlF0lGvUs6/Mp4V9gEhao/nBKUQiz5OdoCGGxOQ2c N/vYwOqtTieRowqr2XWL/kMRSQRi8XTeqZQl94IZHip4qLHmZROukB+lbpCFuDIiMvUG OB4zcRhDG1RLw6bJIuH6m8jgDDpIrx1JWq12gCJX5ItSoqzeZVtyrlgBkb5go0zXfdq/ zwymc23VyHnp4htwZrCioOY5gb8OMnsSH7lMt3KPFOP2BOw1YepMePgxrbtNo3y/fW2G IcXQ== Received: by 10.236.125.130 with SMTP id z2mr24197886yhh.94.1331016103878; Mon, 05 Mar 2012 22:41:43 -0800 (PST) Received: from [192.168.123.102] ([186.134.8.162]) by mx.google.com with ESMTPS id e45sm46685183yhk.2.2012.03.05.22.41.41 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 22:41:42 -0800 (PST) Sender: Fernando Gont Message-ID: <4F55B1A2.7000909@gont.com.ar> Date: Tue, 06 Mar 2012 03:41:38 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Andrew Yourtchenko References: In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, mircea.pisica@bt.com, sasad@cisco.com Subject: Re: [OPSEC] New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:41:45 -0000 Hi, Andrew, I read the I-D. Here are some comments: * Section 4 states: The problem is twofold: first, from the security point of view, one should try to avoid the easy to guess patterns that the traditional address assignment entails. At the same time, the naive approach of assigning purely random addresses to servers is not very scalable in real world for maintenance reasons I think this one is somewhat incorrect: What's usually deemed as hard to manage is temporary addresses (RFC 4941), rather than the fact that the identifiers are random (see e.g., ). * Section 5 states: The idea is to exploit the randomness property of the encryption function output. The interface identifier, used within the IPv6 address of the host, would be derived from the 64-bit data corresponding to hostname, encrypted with a site-wide "secret". How would you distribute the secret. That aside: have you read . It solves the scanning problem and the management problem, with no need to distribute secrets. Thanks, Fernando On 03/05/2012 08:06 AM, Andrew Yourtchenko wrote: > Hi all, > > We will be very thankful for the review/comments on this draft and hope > to present it in Paris. > > --a > > ---------- Forwarded message ---------- > Date: Mon, 05 Mar 2012 03:04:14 -0800 > From: internet-drafts@ietf.org > To: ayourtch@cisco.com > Cc: mircea.pisica@bt.com, sasad@cisco.com > Subject: New Version Notification for > draft-yourtchenko-opsec-humansafe-ipv6-00.txt > > A new version of I-D, draft-yourtchenko-opsec-humansafe-ipv6-00.txt has > been successfully submitted by Andrew Yourtchenko and posted to the IETF > repository. > > Filename: draft-yourtchenko-opsec-humansafe-ipv6 > Revision: 00 > Title: Human-safe IPv6: Cryptographic transformation of > hostnames as a base for secure and manageable addressing > Creation date: 2012-03-02 > WG ID: Individual Submission > Number of pages: 9 > > Abstract: > Although the IPv6 address space within a single /64 subnet is very > large, the typical distribution of the addresses in this space is > very non-uniform. This non-uniformity, together with the dictionary- > based DNS brute-force enumeration, allows practical remote mapping of > the IPv6 addresses in these subnets. This document proposes a > technique which can be used to decrease the exposure of the server > subnets to trivial scanning. As a side effect, the proposed > technique allows to drastically simplify the address management. > > > > > The IETF Secretariat > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From gvandeve@cisco.com Tue Mar 6 01:39:07 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87F221F8865 for ; Tue, 6 Mar 2012 01:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.513 X-Spam-Level: X-Spam-Status: No, score=-10.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KL2zRc26ZiUb for ; Tue, 6 Mar 2012 01:39:06 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9BFC421F8864 for ; Tue, 6 Mar 2012 01:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=2372; q=dns/txt; s=iport; t=1331026746; x=1332236346; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=a65UwskKlKkXvqKroa/fdIe2MHMJVvdzZY2UTCWctfk=; b=aUgsCCXfF9kwNVsNGs8CA9T7c6MGEOiPEb1NT4+loNlVYxmLuWko2Q4b h4j0hTjLbSGMuju7FEDTBzRygtuIb6s3Ct4YK7DEhTi206EDHxf1Cx1iT AeTGqqrr24UZe/LWpNfO3b1Lf36mHATzyR9V3BvJFV/IRKErL/Pyjz9Io Y=; X-IronPort-AV: E=Sophos;i="4.73,539,1325462400"; d="scan'208";a="131431478" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 06 Mar 2012 09:39:05 +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 q269d5jH015229; Tue, 6 Mar 2012 09:39:05 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 10:39:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Mar 2012 10:39:05 +0100 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC50705CAF3@XMB-AMS-102.cisco.com> In-Reply-To: <4F55ABF9.1090805@gont.com.ar> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] IETF OPSEC WG Deliverables - Thread-Index: Acz7YNlTIWP87Ch2TdKNJM1fnC1cqwAGflMg References: <5C99EC8C99D9BB45AC51D20DC2AD2DC50705C450@XMB-AMS-102.cisco.com> <4F55ABF9.1090805@gont.com.ar> From: "Gunter Van de Velde (gvandeve)" To: "Fernando Gont" X-OriginalArrivalTime: 06 Mar 2012 09:39:05.0801 (UTC) FILETIME=[F8F1BB90:01CCFB7C] Cc: opsec@ietf.org, warren@kumari.net, Ron Bonica Subject: Re: [OPSEC] IETF OPSEC WG Deliverables - X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 09:39:07 -0000 Hi Fernando, They can be found at: http://tools.ietf.org/wg/opsec/ Look at the Expired section: draft-ietf-opsec-filter-caps -09 2007-07-13 Expired=20 draft-ietf-opsec-framework -05 2007-04-03 Expired=20 draft-ietf-opsec-infrastructure-security -01 2007-04-10 Expired=20 draft-ietf-opsec-logging-caps -04 2007-08-24 Expired=20 draft-ietf-opsec-misc-cap -00 2006-02-22 Expired=20 draft-ietf-opsec-nmasc -00 2006-03-01 Expired=20 draft-ietf-opsec-routing-capabilities -03 2007-06-15 Expired G/ -----Original Message----- From: Fernando Gont [mailto:fernando.gont.netbook.win@gmail.com] On Behalf Of Fernando Gont Sent: dinsdag 6 maart 2012 7:17 To: Gunter Van de Velde (gvandeve) Cc: opsec@ietf.org; warren@kumari.net; Ron Bonica Subject: Re: [OPSEC] IETF OPSEC WG Deliverables - Folks, What are the documents that are wg items, and that have not been updated recently? Thanks, Fernando On 03/05/2012 08:42 AM, Gunter Van de Velde (gvandeve) wrote: > Dear all, >=20 > =20 >=20 > In an effort to re-energize the OPSEC WG, we have decided to drop any WG > item which has not been progressed or updated last 2 years, and at the > same time they will also be dropped from the OPSEC WG charter. >=20 > =20 >=20 > Thus, if your draft is NOT updated by the deadline of 12 March 2012 > according the deadline mentioned at > https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF83then it will > be removed from the OPSEC charter. >=20 > =20 >=20 > It is a hard decision to take, however to keep the WG fresh and the > deliverables relevant for this current time, we believe we have to take > this action. >=20 > =20 >=20 > During IETF83 we will revise the charter with input from the WG. >=20 > =20 >=20 > In any case, please find here info if you have questions about OPSEC and > its charter: >=20 > =20 >=20 > http://tools.ietf.org/wg/opsec/ >=20 > https://datatracker.ietf.org/wg/opsec/charter/ >=20 > =20 >=20 > Warren & Gunter >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --=20 Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From ayourtch@cisco.com Tue Mar 6 02:32:38 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9527221F880B for ; Tue, 6 Mar 2012 02:32:38 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8BF0DYVFtw2 for ; Tue, 6 Mar 2012 02:32:38 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9F71521F8741 for ; Tue, 6 Mar 2012 02:32:37 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q26AWaZT002447 for ; Tue, 6 Mar 2012 11:32:36 +0100 (CET) Received: from ams-ayourtch-8719.cisco.com (ams-ayourtch-8719.cisco.com [10.55.144.250]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q26AWVgS021843; Tue, 6 Mar 2012 11:32:32 +0100 (CET) Date: Tue, 6 Mar 2012 11:32:29 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx To: Fernando Gont In-Reply-To: <4F55B1A2.7000909@gont.com.ar> Message-ID: References: <4F55B1A2.7000909@gont.com.ar> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: opsec@ietf.org, mircea.pisica@bt.com, sasad@cisco.com Subject: Re: [OPSEC] New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 10:32:38 -0000 Hi Fernando, Thanks for the comments! inline.. On Tue, 6 Mar 2012, Fernando Gont wrote: > Hi, Andrew, > > I read the I-D. Here are some comments: > > * Section 4 states: > The problem is twofold: first, from the security point of view, one > should try to avoid the easy to guess patterns that the traditional > address assignment entails. At the same time, the naive approach of > assigning purely random addresses to servers is not very scalable in > real world for maintenance reasons > > I think this one is somewhat incorrect: What's usually deemed as hard to > manage is temporary addresses (RFC 4941), rather than the fact that the > identifiers are random (see e.g., > ). No, in this case I'm talking about permanently assigned addresses. It's just that telling the full IPv6 address over the phone or remembering it is a chore. Example: 2001:db8:d923:297a:2068:d95d:cff5:308a. Make an experiment and measure how much it takes to get this address over to someone over the phone, without errors. That's the type of problem I had in mind. > > > * Section 5 states: > The idea is to exploit the randomness property of the encryption > function output. The interface identifier, used within the IPv6 > address of the host, would be derived from the 64-bit data > corresponding to hostname, encrypted with a site-wide "secret". > > How would you distribute the secret. USB stick, for example. Or write it on the wall in the ops room :-) I probably should have not named it a "secret" - the idea was to have it secret enough so that a random script kiddie does not know it, yet it can be easily known by the staff. Any suggestions on how I should rename it so there's less confusion ? > > That aside: have you read > . > It solves the scanning problem and the management problem, with no need > to distribute secrets. It's nice, however it requires changes to host OSes. --a > > Thanks, > Fernando > > > > > On 03/05/2012 08:06 AM, Andrew Yourtchenko wrote: >> Hi all, >> >> We will be very thankful for the review/comments on this draft and hope >> to present it in Paris. >> >> --a >> >> ---------- Forwarded message ---------- >> Date: Mon, 05 Mar 2012 03:04:14 -0800 >> From: internet-drafts@ietf.org >> To: ayourtch@cisco.com >> Cc: mircea.pisica@bt.com, sasad@cisco.com >> Subject: New Version Notification for >> draft-yourtchenko-opsec-humansafe-ipv6-00.txt >> >> A new version of I-D, draft-yourtchenko-opsec-humansafe-ipv6-00.txt has >> been successfully submitted by Andrew Yourtchenko and posted to the IETF >> repository. >> >> Filename: draft-yourtchenko-opsec-humansafe-ipv6 >> Revision: 00 >> Title: Human-safe IPv6: Cryptographic transformation of >> hostnames as a base for secure and manageable addressing >> Creation date: 2012-03-02 >> WG ID: Individual Submission >> Number of pages: 9 >> >> Abstract: >> Although the IPv6 address space within a single /64 subnet is very >> large, the typical distribution of the addresses in this space is >> very non-uniform. This non-uniformity, together with the dictionary- >> based DNS brute-force enumeration, allows practical remote mapping of >> the IPv6 addresses in these subnets. This document proposes a >> technique which can be used to decrease the exposure of the server >> subnets to trivial scanning. As a side effect, the proposed >> technique allows to drastically simplify the address management. >> >> >> >> >> The IETF Secretariat >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >> > > > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > From fgont@si6networks.com Tue Mar 6 04:28:23 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1D121F882D for ; Tue, 6 Mar 2012 04:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCfat-J2RZg0 for ; Tue, 6 Mar 2012 04:28:23 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id BB10E21F8826 for ; Tue, 6 Mar 2012 04:28:22 -0800 (PST) Received: from [2001:5c0:1000:a::6a1] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S4tV4-00023o-D5; Tue, 06 Mar 2012 13:28:18 +0100 Message-ID: <4F5602DA.2010806@si6networks.com> Date: Tue, 06 Mar 2012 09:28:10 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Andrew Yourtchenko References: <4F55B1A2.7000909@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, mircea.pisica@bt.com, sasad@cisco.com Subject: Re: [OPSEC] New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 12:28:24 -0000 Hi, Andrew, On 03/06/2012 07:32 AM, Andrew Yourtchenko wrote: >> I think this one is somewhat incorrect: What's usually deemed as hard to >> manage is temporary addresses (RFC 4941), rather than the fact that the >> identifiers are random (see e.g., >> ). > > No, in this case I'm talking about permanently assigned addresses. It's > just that telling the full IPv6 address over the phone or remembering it > is a chore. It wasn't clear to me that you were referring to this problem. > Example: 2001:db8:d923:297a:2068:d95d:cff5:308a. Make an experiment and > measure how much it takes to get this address over to someone over the > phone, without errors. That's the type of problem I had in mind. I know of quite a few folks that have already established the rule that "you don't tell IPv6 addresses over the phone" >> * Section 5 states: >> The idea is to exploit the randomness property of the encryption >> function output. The interface identifier, used within the IPv6 >> address of the host, would be derived from the 64-bit data >> corresponding to hostname, encrypted with a site-wide "secret". >> >> How would you distribute the secret. > > USB stick, for example. Or write it on the wall in the ops room :-) BTW, what are the types of systems that you have in mind for using this? Host? Servers? Routers? All of them? > I probably should have not named it a "secret" - the idea was to have it > secret enough so that a random script kiddie does not know it, yet it > can be easily known by the staff. Any suggestions on how I should rename > it so there's less confusion ? Well, as far as the attacker is concerned, the "secret" is secret. So the term is okay. But I guess it should be more clear to whom the "secret" is secret, and how you plan to distribute it. >> That aside: have you read >> . >> >> It solves the scanning problem and the management problem, with no need >> to distribute secrets. > > It's nice, however it requires changes to host OSes. Well, yes... but that's what you need to do to fix the underlying problem of vulnerability to scanning... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ayourtch@cisco.com Tue Mar 6 05:06:57 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9186C21F88EC for ; Tue, 6 Mar 2012 05:06:57 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs0f9U3trpXC for ; Tue, 6 Mar 2012 05:06:56 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 1371321F88E4 for ; Tue, 6 Mar 2012 05:06:46 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q26D6jnJ021808 for ; Tue, 6 Mar 2012 14:06:46 +0100 (CET) Received: from ams-ayourtch-8719.cisco.com (ams-ayourtch-8719.cisco.com [10.55.144.250]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q26D6h5B024704; Tue, 6 Mar 2012 14:06:43 +0100 (CET) Date: Tue, 6 Mar 2012 14:06:42 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx To: Fernando Gont In-Reply-To: <4F5602DA.2010806@si6networks.com> Message-ID: References: <4F55B1A2.7000909@gont.com.ar> <4F5602DA.2010806@si6networks.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: opsec@ietf.org, mircea.pisica@bt.com, sasad@cisco.com Subject: Re: [OPSEC] New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:06:57 -0000 Hi Fernando, On Tue, 6 Mar 2012, Fernando Gont wrote: > Hi, Andrew, > > On 03/06/2012 07:32 AM, Andrew Yourtchenko wrote: >>> I think this one is somewhat incorrect: What's usually deemed as hard to >>> manage is temporary addresses (RFC 4941), rather than the fact that the >>> identifiers are random (see e.g., >>> ). >> >> No, in this case I'm talking about permanently assigned addresses. It's >> just that telling the full IPv6 address over the phone or remembering it >> is a chore. > > It wasn't clear to me that you were referring to this problem. Thanks! I will add the wording to make it more explicit. > > > >> Example: 2001:db8:d923:297a:2068:d95d:cff5:308a. Make an experiment and >> measure how much it takes to get this address over to someone over the >> phone, without errors. That's the type of problem I had in mind. > > I know of quite a few folks that have already established the rule that > "you don't tell IPv6 addresses over the phone" Indeed, precisely because of this problem, I suspect. > > >>> * Section 5 states: >>> The idea is to exploit the randomness property of the encryption >>> function output. The interface identifier, used within the IPv6 >>> address of the host, would be derived from the 64-bit data >>> corresponding to hostname, encrypted with a site-wide "secret". >>> >>> How would you distribute the secret. >> >> USB stick, for example. Or write it on the wall in the ops room :-) > > BTW, what are the types of systems that you have in mind for using this? > Host? Servers? Routers? All of them? Any of them - the doc does not set the policy on that. One example use will be using this approach for manually assigning link-local addresses to routers - then you can have the router names as next hops in the routing table. Another could be a per-purpose addressing plans where the addresses in one "semantic domain" could use one secret, and the addresses in the other "semantic domain" could use another secret. And the NMS software could distinguish between them. Yet another one is that if you know that your internal addressing follows this pattern, you can put a filter on the ingress firewall, and block the addresses that by definition can not belong to your space. There are many possibilities one can come up with, that's why I did not want to explicitly limit them by enumerating. > > > >> I probably should have not named it a "secret" - the idea was to have it >> secret enough so that a random script kiddie does not know it, yet it >> can be easily known by the staff. Any suggestions on how I should rename >> it so there's less confusion ? > > Well, as far as the attacker is concerned, the "secret" is secret. So > the term is okay. But I guess it should be more clear to whom the > "secret" is secret, and how you plan to distribute it. Thanks, I will put some more text for the next revision. > > >>> That aside: have you read >>> . >>> >>> It solves the scanning problem and the management problem, with no need >>> to distribute secrets. >> >> It's nice, however it requires changes to host OSes. > > Well, yes... but that's what you need to do to fix the underlying > problem of vulnerability to scanning... Not really. From the pure scanning resistance standpoint, the lower /64s need to be as random as possible, that is it. One trivial approach is to manually assign random MAC addresses to each host on the segment. It forces the attacker to scan the 2^48 space, which, even if 65536 times less than the full 2^64, is still a worthy challenge. The only thing it requires is the careful management of MAC addresses - however, this is already a given in some environments (e.g. in UCS) - where the VMs themselves need to have the MAC address assigned from the pool. So, I think there's more than one way to skin a cat, with different tradeoffs. --a > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From fgont@si6networks.com Tue Mar 6 05:51:44 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1168D21F8826 for ; Tue, 6 Mar 2012 05:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8Gxoem2dhOp for ; Tue, 6 Mar 2012 05:51:43 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1667321F862A for ; Tue, 6 Mar 2012 05:51:39 -0800 (PST) Received: from [2001:5c0:1400:a::2d] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S4unf-0002rE-7Q; Tue, 06 Mar 2012 14:51:35 +0100 Message-ID: <4F56164F.301@si6networks.com> Date: Tue, 06 Mar 2012 10:51:11 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Andrew Yourtchenko References: <4F55B1A2.7000909@gont.com.ar> <4F5602DA.2010806@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, mircea.pisica@bt.com, sasad@cisco.com Subject: Re: [OPSEC] New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:51:44 -0000 On 03/06/2012 10:06 AM, Andrew Yourtchenko wrote: >>> Example: 2001:db8:d923:297a:2068:d95d:cff5:308a. Make an experiment and >>> measure how much it takes to get this address over to someone over the >>> phone, without errors. That's the type of problem I had in mind. >> >> I know of quite a few folks that have already established the rule that >> "you don't tell IPv6 addresses over the phone" > > Indeed, precisely because of this problem, I suspect. Exactly. >>>> * Section 5 states: >>>> The idea is to exploit the randomness property of the encryption >>>> function output. The interface identifier, used within the IPv6 >>>> address of the host, would be derived from the 64-bit data >>>> corresponding to hostname, encrypted with a site-wide "secret". >>>> >>>> How would you distribute the secret. >>> >>> USB stick, for example. Or write it on the wall in the ops room :-) >> >> BTW, what are the types of systems that you have in mind for using this? >> Host? Servers? Routers? All of them? > > Any of them - the doc does not set the policy on that. Well, if you do it for clients and servers, you'd need to move away from slaac, at which point this would, by itself be a problem. > One example use > will be using this approach for manually assigning link-local addresses > to routers - then you can have the router names as next hops in the > routing table. Sorry, are you using any specific pattern for the IID that helps to identify whether an address has been generated with this scheme? >>> I probably should have not named it a "secret" - the idea was to have it >>> secret enough so that a random script kiddie does not know it, yet it >>> can be easily known by the staff. Any suggestions on how I should rename >>> it so there's less confusion ? >> >> Well, as far as the attacker is concerned, the "secret" is secret. So >> the term is okay. But I guess it should be more clear to whom the >> "secret" is secret, and how you plan to distribute it. > > Thanks, I will put some more text for the next revision. Another comment: please specify the scheme with a function or pseudocode, such that it's not necessary to go through the sample code to grasp the proposal. >>> It's nice, however it requires changes to host OSes. >> >> Well, yes... but that's what you need to do to fix the underlying >> problem of vulnerability to scanning... > > Not really. From the pure scanning resistance standpoint, the lower /64s > need to be as random as possible, that is it. Yes, but then there's the problem of tracking, and the operational problem of temporary addresses. -- that's where the possible choices get narrowed down. > One trivial approach is to manually assign random MAC addresses to each > host on the segment. It forces the attacker to scan the 2^48 space, > which, even if 65536 times less than the full 2^64, is still a worthy > challenge. The only thing it requires is the careful management of MAC > addresses - however, this is already a given in some environments (e.g. > in UCS) - where the VMs themselves need to have the MAC address assigned > from the pool. At which point it becomes a 2^24 search space, since the OUI is known... Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ayourtch@cisco.com Tue Mar 6 06:35:21 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBA621F887D for ; Tue, 6 Mar 2012 06:35:21 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-aJf2rKmHV9 for ; Tue, 6 Mar 2012 06:35:20 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 3266E21F8864 for ; Tue, 6 Mar 2012 06:35:20 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q26EZGaA002839 for ; Tue, 6 Mar 2012 15:35:16 +0100 (CET) Received: from ams-ayourtch-8719.cisco.com (ams-ayourtch-8719.cisco.com [10.55.144.250]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q26EZE9G023976; Tue, 6 Mar 2012 15:35:14 +0100 (CET) Date: Tue, 6 Mar 2012 15:35:12 +0100 (CET) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx To: Fernando Gont In-Reply-To: <4F56164F.301@si6networks.com> Message-ID: References: <4F55B1A2.7000909@gont.com.ar> <4F5602DA.2010806@si6networks.com> <4F56164F.301@si6networks.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: opsec@ietf.org, mircea.pisica@bt.com, sasad@cisco.com Subject: Re: [OPSEC] New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 14:35:21 -0000 On Tue, 6 Mar 2012, Fernando Gont wrote: > On 03/06/2012 10:06 AM, Andrew Yourtchenko wrote: >>>> Example: 2001:db8:d923:297a:2068:d95d:cff5:308a. Make an experiment and >>>> measure how much it takes to get this address over to someone over the >>>> phone, without errors. That's the type of problem I had in mind. >>> >>> I know of quite a few folks that have already established the rule that >>> "you don't tell IPv6 addresses over the phone" >> >> Indeed, precisely because of this problem, I suspect. > > Exactly. > This approach could address it, I believe. > > >>>>> * Section 5 states: >>>>> The idea is to exploit the randomness property of the encryption >>>>> function output. The interface identifier, used within the IPv6 >>>>> address of the host, would be derived from the 64-bit data >>>>> corresponding to hostname, encrypted with a site-wide "secret". >>>>> >>>>> How would you distribute the secret. >>>> >>>> USB stick, for example. Or write it on the wall in the ops room :-) >>> >>> BTW, what are the types of systems that you have in mind for using this? >>> Host? Servers? Routers? All of them? >> >> Any of them - the doc does not set the policy on that. > > Well, if you do it for clients and servers, you'd need to move away from > slaac, at which point this would, by itself be a problem. Again, at this stage I am not focusing at a particular use case. > > >> One example use >> will be using this approach for manually assigning link-local addresses >> to routers - then you can have the router names as next hops in the >> routing table. > > Sorry, are you using any specific pattern for the IID that helps to > identify whether an address has been generated with this scheme? The address that was not generated with the correct secret will most probably fail to decrypt correctly. You can try the code. Though would be good if you could help with some hard math on what is the probability of the false positives in this scenario. > > > >>>> I probably should have not named it a "secret" - the idea was to have it >>>> secret enough so that a random script kiddie does not know it, yet it >>>> can be easily known by the staff. Any suggestions on how I should rename >>>> it so there's less confusion ? >>> >>> Well, as far as the attacker is concerned, the "secret" is secret. So >>> the term is okay. But I guess it should be more clear to whom the >>> "secret" is secret, and how you plan to distribute it. >> >> Thanks, I will put some more text for the next revision. > > Another comment: please specify the scheme with a function or > pseudocode, such that it's not necessary to go through the sample code > to grasp the proposal. > Any suggestions on the text ? I have in mind something like this, in a new section: "Reference Implementation The reference implementation derives the Interface Identifier by performing a logical XOR operation between the /64 prefix and the result of encrypting of the 8 characters of the hostname with an arbitrary network-wide secret. The reverse transformation can be used to verify the address / extract the hostname." Would that be clear enough ? > > >>>> It's nice, however it requires changes to host OSes. >>> >>> Well, yes... but that's what you need to do to fix the underlying >>> problem of vulnerability to scanning... >> >> Not really. From the pure scanning resistance standpoint, the lower /64s >> need to be as random as possible, that is it. > > Yes, but then there's the problem of tracking, and the operational > problem of temporary addresses. -- that's where the possible choices get > narrowed down. > It is a separate problem, even if interrelated. But my point was that changes on the hosts is only one of the ways to address this. > > >> One trivial approach is to manually assign random MAC addresses to each >> host on the segment. It forces the attacker to scan the 2^48 space, >> which, even if 65536 times less than the full 2^64, is still a worthy >> challenge. The only thing it requires is the careful management of MAC >> addresses - however, this is already a given in some environments (e.g. >> in UCS) - where the VMs themselves need to have the MAC address assigned >> from the pool. > > At which point it becomes a 2^24 search space, since the OUI is known... No. Strictly speaking it's 2^46 space. I flip the bit to specify the MAC address is locally administered, and there's no OUIs anymore because the *entire* MAC is generated randomly, minus the two bits. --a > > Thanks, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > From fernando.gont.netbook.win@gmail.com Tue Mar 6 14:47:04 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B1421F85E6 for ; Tue, 6 Mar 2012 14:47:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3Cp-FH1VkA6 for ; Tue, 6 Mar 2012 14:47:04 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id E5F6021F85E1 for ; Tue, 6 Mar 2012 14:47:03 -0800 (PST) Received: by yhpp34 with SMTP id p34so2906171yhp.31 for ; Tue, 06 Mar 2012 14:47:03 -0800 (PST) Received-SPF: pass (google.com: domain of fernando.gont.netbook.win@gmail.com designates 10.236.77.102 as permitted sender) client-ip=10.236.77.102; Authentication-Results: mr.google.com; spf=pass (google.com: domain of fernando.gont.netbook.win@gmail.com designates 10.236.77.102 as permitted sender) smtp.mail=fernando.gont.netbook.win@gmail.com; dkim=pass header.i=fernando.gont.netbook.win@gmail.com Received: from mr.google.com ([10.236.77.102]) by 10.236.77.102 with SMTP id c66mr38311042yhe.30.1331074023644 (num_hops = 1); Tue, 06 Mar 2012 14:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=PTr/e3YWkKFZzlXeH+tiPGp5o6GaTRlCl+/qHnHBgyc=; b=XcvZEfgn5+Zk4ABRGlSBiAILvRF33A86ooqscBQVEsaagVJWdyTNNezonZ9SRVEOnd BIr9qgTGBnmAGRo3sOoozlN4TR0Jz8TEqwdv5Y/ridxKwXgQLZbjE8mpvBg9r1O8qX7u cbqHWxuaXB+TybP633w/9xWhMDz2A9fWaRQ9N4OmVZ0Wgh1A2qjEKj0TtDgYXGFBmyhZ V7BYen1M0soUr9fZ6Q5fHuFy9XC/cNtqpdmw1o3l5n3e+ZFJPWzLxK6+Rxj6248z+rFS PXOiHSu1OSO9iseBkt3x+UviYTaSyJVfUaqh56lFK3rqM2Hc1JK5o1A8PiKQpoE5Et+w CCnA== Received: by 10.236.77.102 with SMTP id c66mr30367512yhe.30.1331074023597; Tue, 06 Mar 2012 14:47:03 -0800 (PST) Received: from [192.168.123.102] ([186.134.8.162]) by mx.google.com with ESMTPS id v21sm52787086yhk.3.2012.03.06.14.46.59 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 14:47:02 -0800 (PST) Sender: Fernando Gont Message-ID: <4F5693DB.3020801@gont.com.ar> Date: Tue, 06 Mar 2012 19:46:51 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Andrew Yourtchenko References: <4F55B1A2.7000909@gont.com.ar> <4F5602DA.2010806@si6networks.com> <4F56164F.301@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Fernando Gont , opsec@ietf.org, mircea.pisica@bt.com, sasad@cisco.com Subject: Re: [OPSEC] New Version Notification for draft-yourtchenko-opsec-humansafe-ipv6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:47:04 -0000 Hi, Andrew, On 03/06/2012 11:35 AM, Andrew Yourtchenko wrote: >>>> BTW, what are the types of systems that you have in mind for using >>>> this? >>>> Host? Servers? Routers? All of them? >>> >>> Any of them - the doc does not set the policy on that. >> >> Well, if you do it for clients and servers, you'd need to move away from >> slaac, at which point this would, by itself be a problem. > > Again, at this stage I am not focusing at a particular use case. I'm just noting that for nodes that already require manual configuration, this technique might be feasible, but for those that don't, this would impose other management burden (starting with disabling slaac). >>> One example use >>> will be using this approach for manually assigning link-local addresses >>> to routers - then you can have the router names as next hops in the >>> routing table. >> >> Sorry, are you using any specific pattern for the IID that helps to >> identify whether an address has been generated with this scheme? > > The address that was not generated with the correct secret will most > probably fail to decrypt correctly. It seems I need to look at the address more carefully, then. >> Another comment: please specify the scheme with a function or >> pseudocode, such that it's not necessary to go through the sample code >> to grasp the proposal. >> > > Any suggestions on the text ? I have in mind something like this, in a > new section: Avoid text, and use an expression. See e.g. how we specified the TCP SEQ generation scheme in RFC 6528. >>> One trivial approach is to manually assign random MAC addresses to each >>> host on the segment. It forces the attacker to scan the 2^48 space, >>> which, even if 65536 times less than the full 2^64, is still a worthy >>> challenge. The only thing it requires is the careful management of MAC >>> addresses - however, this is already a given in some environments (e.g. >>> in UCS) - where the VMs themselves need to have the MAC address assigned >>> from the pool. >> >> At which point it becomes a 2^24 search space, since the OUI is known... > > No. Strictly speaking it's 2^46 space. I flip the bit to specify the MAC > address is locally administered, and there's no OUIs anymore because the > *entire* MAC is generated randomly, minus the two bits. Agreed. However, msot virtualization technologies seem to use, by default, a specific OUI rather than setting the U/L bit to 1 and randomizing the other 2^46 bits. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fred@cisco.com Wed Mar 7 22:29:15 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65B821F869A for ; Wed, 7 Mar 2012 22:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.837 X-Spam-Level: X-Spam-Status: No, score=-108.837 tagged_above=-999 required=5 tests=[AWL=1.718, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBNFDPpOzbkz for ; Wed, 7 Mar 2012 22:29:14 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id BB3F721F8691 for ; Wed, 7 Mar 2012 22:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=75; q=dns/txt; s=iport; t=1331188154; x=1332397754; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=1FyS34ITX1IeLeowaEBXiXSHuLom4jV80pgsGDg/oXQ=; b=GtsheNeUrgdru31H2B7B7CvDdwSLv1dMZrwnLTyEAImGeZuoLyweMMOk i62djv3TPylhjglnpL/RZ1e0BLm3PzGEQJ+HRhr74va/gQLHiSVhDWFaU xZuanDv/L1Uk46Fw5MOcaMdFR//1mDfVERRyrT2zJzCSd3oh3QxwkMAKE U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEIAFlRWE+rRDoG/2dsb2JhbABDJrUFgQeCIwEnP4Fzh2WbAQGfFI1Mgj9jBIhQjHGFZIozgnI X-IronPort-AV: E=Sophos;i="4.73,550,1325462400"; d="scan'208";a="34969154" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 08 Mar 2012 06:29:14 +0000 Received: from Freds-Computer.local (tky-vpn-client-231-56.cisco.com [10.70.231.56]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q286TBaE021953; Thu, 8 Mar 2012 06:29:14 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 08 Mar 2012 15:29:14 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 08 Mar 2012 15:29:14 +0900 From: Fred Baker Date: Thu, 8 Mar 2012 12:28:37 +0900 Message-Id: <2BCA414C-1958-489C-977C-5255B1665B26@cisco.com> To: opsec-chairs@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org Subject: [OPSEC] draft-baker-opsec-passive-ip-address-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 06:29:15 -0000 Gunter or I would appreciate and opportunity to discuss this with the WG. From gvandeve@cisco.com Thu Mar 8 14:23:35 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5287F21E8065; Thu, 8 Mar 2012 14:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.519 X-Spam-Level: X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-dLYY70dcu1; Thu, 8 Mar 2012 14:23:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFAE21F8622; Thu, 8 Mar 2012 14:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1197; q=dns/txt; s=iport; t=1331245414; x=1332455014; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=SorALjr2JQ5E65Hrr2p1276RaT2vUK5NAyhDyw+qrfg=; b=QPbbYqH84wg/NWW2Y5vMJgUrgnQoCpw+JZU3DZq4nr/uE7iAQfcTS+rr ZYFTMtu/QP0LQDxH4hOIdFYUwgJ16pVnlcY37EV3MW/jq6NhXB84+cm7h kg0DoHWogEgBUkbMLZrsFYq6+qyXk9V7XvV8ssaQgRgLFMKlUPvJVJooJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAwwWU+Q/khR/2dsb2JhbABDtSmBB4ILAQEEEgEdCj8QAgEIIgYYBgFWAQEEARoTB4doC5s+AZ54j3NjBKVdgmQ X-IronPort-AV: E=Sophos;i="4.73,554,1325462400"; d="scan'208";a="131768119" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2012 22:23:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q28MNW4A015913; Thu, 8 Mar 2012 22:23:32 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 23:23:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: FT2B HRvN M8hf OGLw ORAL OZJ/ PWlV Uwmf WFy4 ZJeM bErj cNI8 gRxo kcoZ lJiU nwzH; 4; YgByAGkAYQBuAC4AZQAuAGMAYQByAHAAZQBuAHQAZQByAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBnAGUAcgB0AEAAcwBwAGEAYwBlAC4AbgBlAHQAOwBvAHAAcwBlAGMAQABpAGUAdABmAC4AbwByAGcAOwB2ADYAbwBwAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {B833A991-48A8-41A0-B8E2-44C874B02303}; ZwB2AGEAbgBkAGUAdgBlAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Thu, 08 Mar 2012 22:23:23 GMT; UgBFADoAIABbAHYANgBvAHAAcwBdACAATgBlAHcAIABEAHIAYQBmAHQAOgAgAFUAcwBpAG4AZwAgAE8AbgBsAHkAIABMAGkAbgBrAC0ATABvAGMAYQBsACAAQQBkAGQAcgBlAHMAcwAgAGkAbgAgAE4AZQB0AHcAbwByAGsACQBDAG8AcgBlAA== MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {B833A991-48A8-41A0-B8E2-44C874B02303} Content-class: urn:content-classes:message Date: Thu, 8 Mar 2012 23:23:23 +0100 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC5070CC4AB@XMB-AMS-102.cisco.com> In-Reply-To: <4F59090D.8000901@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core Thread-Index: Acz9YhvAQlm+ygg7QLmlUlJzCncvFQAFoSKQ References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> <20120308173038.GI84425@Space.Net> <20120308173712.GT22535@angus.ind.WPI.EDU><20120308175526.GK84425@Space.Net> <4F59090D.8000901@gmail.com> From: "Gunter Van de Velde (gvandeve)" To: "Brian E Carpenter" , "Gert Doering" X-OriginalArrivalTime: 08 Mar 2012 22:23:32.0332 (UTC) FILETIME=[185A72C0:01CCFD7A] Cc: v6ops@ietf.org, opsec@ietf.org Subject: Re: [OPSEC] [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 22:23:35 -0000 >On the same point: > >>> Traceroute: Similar to the ping case, a reply to a traceroute packet >>> would come from a loopback address with a global address. Today this >>> does not display the specific interface the packets came in on. Also >>> here, RFC5837 [RFC5837] provides a solution. > >There is a genuine source of confusion possible here for a typical >traceroute user, even if not interested in the specific interface. >I've seen cases where the traceroute reply came from a global address >that was actually a PA address from an ISP that was not actually >on the path, because the router had multiple interfaces with PA >addresses from several ISPs. So it's actually important that the >global address used for ICMP replies, even if it's a loopback address, >is under a prefix that belongs to the organisation operating the router >in question. Also Passive-IPv6 addresses provide a way to have traceroute capabilities again to complement a LL-only infrastructure. (http://tools.ietf.org/html/draft-baker-opsec-passive-ip-address-00) The convenient element is that it doesn't require the ICMP stack to be changed and is box only behavior G/ From cpignata@cisco.com Sat Mar 10 09:45:10 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B8A21F857A for ; Sat, 10 Mar 2012 09:45:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.522 X-Spam-Level: X-Spam-Status: No, score=-109.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA-NGWeJNeyj for ; Sat, 10 Mar 2012 09:45:08 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8879721F8569 for ; Sat, 10 Mar 2012 09:45:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=32177; q=dns/txt; s=iport; t=1331401508; x=1332611108; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=wcSFDgvPTVAqYB9kuKsHuKiFemC4t/P1bv/37NWdW0o=; b=kCmmroDGXRXDC7pPDXqqAta2hNetrGmpO7Qku/gqgkwewkqqmixpvOwZ 6L0u1Qf0z48fcBK3PwN3ParZQGduTy4/MlEiBVICWLYKh2TM3zYZHs0MV mEY0wRWgQ9kcWzNuJSba2CMUUEzzUXyH6C/7JyAOEZOYHw3lEoJ7p/0v7 0=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmwFAMaSW0+rRDoI/2dsb2JhbABDFqw2AYhygQeCCQEBAQMBAQEBDwEHDQY/AggBAgULHAEDAQEBIAMEBycfAwYIBhMJGYdjBAybcAGeJIo1hWljBIhUhgeGcZAjgwGBPg X-IronPort-AV: E=Sophos;i="4.73,563,1325462400"; d="asc'?scan'208,217";a="35391567" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 10 Mar 2012 17:45:07 +0000 Received: from rtp-cpignata-89110.cisco.com (rtp-cpignata-89110.cisco.com [10.117.115.59]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2AHj6N4017758; Sat, 10 Mar 2012 17:45:07 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_8D95D764-6328-435C-BE04-01775B33D13B"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Carlos Pignataro In-Reply-To: <9501DDFF-BBAD-4812-B08C-C2A98084CB83@mimectl> Date: Sat, 10 Mar 2012 12:45:06 -0500 Message-Id: <4BF98148-82B4-4B75-96B2-556A52C0F901@cisco.com> References: <4DB74CBD.2050003@gont.com.ar> <4DCCA138.2000908@cisco.com><4DD5F510.5060405@gont.com.ar> <4DF8D73F.7020803@cisco.com><4EEC00AD.8020702@gont.com.ar> <4F1DA31E.5080608@cisco.com>, <4F1DC29D.5050209@gont.com.ar> <9501DDFF-BBAD-4812-B08C-C2A98084CB83@mimectl> To: "Smith, Donald" X-Mailer: Apple Mail (2.1257) Cc: opsec@ietf.org, Fernando Gont Subject: [OPSEC] ietf-opsec-icmp-filtering (Was: New Version Notification fordraft-gont-opsec-ip-options-filtering-01) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 17:45:10 -0000 --Apple-Mail=_8D95D764-6328-435C-BE04-01775B33D13B Content-Type: multipart/alternative; boundary="Apple-Mail=_0235BF91-097C-48A0-8265-E7E999361188" --Apple-Mail=_0235BF91-097C-48A0-8265-E7E999361188 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Donald, Apologies for a late response. To set the context of this email (ICMP = filtering and not IP Options) I updated the Subject line. Please see inline. On Feb 20, 2012, at 7:13 PM, Smith, Donald wrote: > I have read this in the past but it has changed enough to require that = I read it again a few times:) I like the concept and agree with most of = what you have. >=20 Great -- and thanks again for the thorough review and comments! >=20 > Legend is incomplete, Deny, Permit, Send and N/A are undefined. I = realize they are sort of self explanatory but it may help to define = them. For example deny do you mean silent drop or reset or send icmp = errors or ...? >=20 Ack. > Deprecated options may still be in use so we may want to think about = if we want to add an "action" to that. Is it apparent that the filtering = is for routers only or routers and hosts or routers and hosts and = firewalls? > Firewalls tend to block a lot more then routers. They also incorrect = use icmp errors to block certain types of packets/protocols etc... For = example iptables sends port unreachable error msgs for all reject's. = That can be modified but that is the default. >=20 >=20 I think you clarified this comment in a subsequent email. > Also the concept at edge of net, internal net etc... seem to be = important but not covered by the table which may be ok just pointing = that out. So while we might filter some packets out at the edge of the = network we may allow them internally. For example I wouldn't want a icmp = redirect to come from outside my network but may allow it internally = same for TOS/df bits. I wouldn't want someone controlling which queue = they get into on my routers but may want to use TOS within my network. >=20 >=20 Do you think that this comment should be incorporated in a specific = section? do you have some specific text in mind? >=20 > I am not sure I agree with all your recommendations in the table but = that is going to require I read it a few times before making any = suggestions. >=20 > Threats could probably be defined somewhere in full then use a similar = abbreviation as you have done in the table to refer to them. > Something like "redirect =3D Can be used to redirect all or some = traffic to a site to compromise availability, integrity and = confidentiality" > DOS =3D Resource Exhaustion =3D Can be used to exhaust bandwidth, cpu, = io or other scarce resources by consuming too much of a resource either = by causing the device to generate a lot of msgs or by sending directly = towards device. >=20 > Operational and interop impact could be done the same way since those = are mostly the same or come from a small set of impacts. >=20 >=20 I see, but the threats are not included in the table, only the = recommendations. Do you still feel like having specific definition for = each threat would help, if we do not cite them from a common place, = instead of having more flexibility with the text at each section? > You state in at least one spot that many stacks ignore an type/code = pair but some other type/codes commonly ignored don't have that = statement. >=20 >=20 That would be a gap to fix. Which specific type/codes are currently = commonly ignored but it is not mentioned in the corresponding section? Thanks again! -- Carlos. >=20 > (coffee !=3D sleep) & (!coffee =3D=3D sleep) > Donald.Smith@qwest.com > ________________________________ > From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of = Fernando Gont [fernando@gont.com.ar] > Sent: Monday, January 23, 2012 1:27 PM > To: Carlos Pignataro > Cc: 'opsec@ietf.org' > Subject: Re: [OPSEC] Fwd: New Version Notification for = draft-gont-opsec-ip-options-filtering-01 >=20 > Hi, Carlos, >=20 > Is there anything that still need to be addressed in the document? > (modulo nits and the quick fixes you highlighted in your last e-mail)? >=20 > Thanks, > Fernando >=20 >=20 >=20 >=20 > On 01/23/2012 03:12 PM, Carlos Pignataro wrote: >=20 > > On 12/16/2011 9:38 PM, Fernando Gont wrote: > >> Hi, Carlos, > >> > >> My apologies for the delay in my response. Please find my comments = inline... > >> > >> On 06/15/2011 01:01 PM, Carlos Pignataro wrote: > >>> In a way, the comment behind my comment was that if today optioned > >>> packets are already mostly blocked/filtered out, the value of a > >>> per-option analysis decreases. > >>> > >>> Dan Wing was kind enough to run his experiment with existing = options (as > >>> opposed to unknown options), with these results: > >>> > >>> Without any IP options: > >>> # grep open normal-nop.out | wc > >>> 486 2430 29901 > >> > >> Sorry, what does each of the columns stand for? > >> > > > > This is the standard output of `wc` (word count), where the columns = are > > number of lines, words, and characters, respectively. Only the first > > column is meaningful here (wc -l), and the important piece was that = you > > get only a 3.29% success when using known options. > > > > Without any IP options: > > # grep open normal-nop.out | wc > > 486 2430 29901 > > ^^^ > > with just NOP, NOP, NOP, EOL: // --ip-options \x01\x01\x01\x00 > > # grep open ip-options-nop.out | wc > > 16 80 1099 > > ^^ > > And 16 is a 3.29% of 486. > > > > [BTW: the script is at ] > > > >> > >> > >>> I am not aware of papers with more scientific analysis of success = rates > >>> with existing options. But: > >>> > >>> --->8--- > >>> Data seems to indicate that there is a current widespread > >>> practice of blocking IPv4 optioned packets. There are various > >>> plausible approaches to minimize the potential negative = effects > >>> of IPv4 optioned packets while allowing some options = semantics. > >>> One approach is to allow for specific options that are = expected > >>> or needed, and a default deny. A different approach is to = deny > >>> unneeded options and a default allow. Yet a third option is = to > >>> allow for end-to-end semantics by ignoring options and = treating > >>> packets as unoptioned while in transit. The current state = tends > >>> to support the first or third approaches as more realistic. > >>> --->8--- > >> > >> I've added this (verbatim) to the intro, and have also added a = pointer > >> to Medina's paper. > >> > > > > Ack -- Thanks! > > > >> > >>>>> 2. It assumes that devices (i.e., routers) have the capability = to filter > >>>>> IP optioned packets with the per-option-value granularity. This = might > >>>>> not generally be the case. > >>> > >>> I think this point should also be clarified. > >> > >> Done in the intro (right bellow the text you suggested above): > >> > >> --- cut here --- > >> We also note that while this document provides advice on a "per IP > >> option type", not all devices may provide functionality to filter = IP > >> packets on a "per IP option type". Additionally, even in cases in = which > >> such functionality is provided, the operator might want to specify = a > >> filtering policy with a coarser granularity (rather than on a "per = IP > >> option type" granularity), as indicated above. > >> ---- cut here --- > >> > > > > Thanks. > > > >> > >>>> I disagree with this assessment. The document assesses the impact = of > >>>> filtering different options. If you're fine with the impact of = filtering > >>>> all ip-optioned packets, then you don't need to filter at the > >>>> granularity of per-option-type. > >>> > >>> I guess what I was thinking is that an operator could think "what = do I > >>> lose if I block this option" and do that exercise for every = option, or > >>> "what do I gain by allowing", and this is where the (apparent) = current > >>> practice has a role in deciding this. > >> > >> I think this is addressed by the text that you've provided? > >> > > > > I think so, I will re-read it too. > > > >> > >>>>> Additionally, > >>>>> > >>>>> 4. There may be more than "filter" versus "not-filter" options. = Some > >>>>> platforms support ignoring IP options (i.e., acting as if an IP = Optioned > >>>>> packet did not have options), and that is a potential = recommendation. > >>>> > >>>> IIRC, this is already mentioned in the document. > >>>> > >>> > >>> I could not find it. Could you please point to the specific para? > >>> > >>> I think this is quite important because I think this is another = practice > >>> often seen as the best option. > >> > >> You were right -- it wasn't there. I have added this to the intro: > >> > >> ---- cut here ---- > >> Finally, in scenarios in which processing of IP options by = intermediate > >> systems is not required, a widespread approach is to simply ignore = IP > >> options, and processs the corresponding packets as if they do not > >> contain any IP options. > >> --- cut here --- > >> > > > > Thanks -- note a typo, s/processs/process/; > > > >> > >>>>> The first sentence of Section 3, "Router manufacturers tend to = do IP > >>>>> option processing on the main processor, rather than on line = cards", > >>>>> speaks to specific router distributed architecture, and I think = it might > >>>>> be oversimplifying the current state. > >>>> > >>>> Proposed change? > >>> > >>> http://tools.ietf.org/html/rfc6192#section-1 > >>> > >>> Modern router architecture design maintains a strict separation = of > >>> forwarding and router control plane hardware and software. The > >>> > >>> There are possible things like ICMP generation and IP option = processing > >>> on general use processors in Line Cards, as opposed to LC = forwarding > >>> ASICs. It is a punt to a slower path. But not necessarily a punt = to the > >>> RP -- there may not be "main processor" but "main processors" = depending > >>> on the context, and abstracting from actual architectures helps = the > >>> document be more time invariant. > >> > >> How about changing the text to: > >> "Router manufacturers tend to do IP option processing in slower = path. > > ^"a" > >> Unless special care is taken, this represents Denial of Service = (DoS) > > ^ "a potential" > >> risk, as there is potential for overwhelming the router with option > > ^^^^^^^^^^^^^^^^^^^^^^^ > > I'd remove this and add "if protective measures are not = taken". > >> processing." > >> ? > >> > > > > Looks good, modulo quick comments. > > > >> > >>>>> For EOO and NOOP, the advise is to: > >>>>> > >>>>> No security issues are known for this option, other than the = general > >>>>> security implications of IP options discussed in Section 2. > >>>>> > >>>>> But I think that the general implications are the most important = part of > >>>>> this document but are minimal. > >>>> > >>>> hence? > >>> > >>> Well, Section 2 is the default gateway for general implications > >>> applicable to all options but IMHO inadequately covers that = subject. To > >>> be more precise, it does not cover it. > >> > >> Can you specify what (exactly) you're referring to, so that I can > >> improve the document in this respect? > >> > > > > The text says "general security implications of IP options discussed = in > > Section 2", but there are no security implications discussed in S2. > > > >> > >> > >>> Section 2 does not have general security implications of IP = options. It > >>> seems to contain a guide as to what options are (semantics and = syntax) > >>> but not security implications. > >> > >> I've changed the ref to the one about the processing requirements. > >> Things can be improved from there. > >> > >> P.S.: I've submitted a rev of the document, since it had expired. = It is > >> available at: > >> = . > >> Please take a look and see if any of the issues raised in this = e-mail > >> still needs to be addressed. (It still need to work on other = feedback > >> you provided in other e-mails). > >> > >> Thanks! > >> > >> Best regards, > > > > Sounds good. > > > > Thanks, > > > > -- Carlos. > > >=20 >=20 > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@si6networks.com > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 > ________________________________ > This communication is the property of CenturyLink and may contain = confidential or privileged information. Unauthorized use of this = communication is strictly > prohibited and may be unlawful. If you have received this = communication > in error, please immediately notify the sender by reply e-mail and = destroy > all copies of the communication and any attachments. >=20 >=20 --Apple-Mail=_0235BF91-097C-48A0-8265-E7E999361188 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Donald,

Apologies for a late response. To set the context of this email (ICMP filtering and not IP Options) I updated the Subject line.

Please see inline.

On Feb 20, 2012, at 7:13 PM, Smith, Donald wrote:

RE: [OPSEC] Fwd: New Version Notification fordraft-gont-opsec-ip-options-filtering-01

I have read this in the past but it has changed enough to require that I read it again a few times:) I like the concept and agree with most of what you have.

Great -- and thanks again for the thorough review and comments!


Legend is incomplete, Deny, Permit, Send and N/A are undefined. I realize they are sort of self explanatory but it may help to define them. For example deny do you mean silent drop or reset or send icmp errors or ...?

Ack.

Deprecated options may still be in use so we may want to think about if we want to add an "action" to that. Is it apparent that the filtering is for routers only or routers and hosts or routers and hosts and firewalls?
Firewalls tend to block a lot more then routers. They also incorrect use icmp errors to block certain types of packets/protocols etc... For example iptables sends port unreachable error msgs for all reject's. That can be modified but that is the default.

I think you clarified this comment in a subsequent email.

Also the concept at edge of net, internal net etc... seem to be important but not covered by the table which may be ok just pointing that out. So while we might filter some packets out at the edge of the network we may allow them internally. For example I wouldn't want a icmp redirect to come from outside my network but may allow it internally same for TOS/df bits. I wouldn't want someone controlling which queue they get into on my routers but may want to use TOS within my network.

Do you think that this comment should be incorporated in a specific section? do you have some specific text in mind?


I am not sure I agree with all your recommendations in the table but that is going to require I read it a few times before making any suggestions.

Threats could probably be defined somewhere in full then use a similar abbreviation as you have done in the table to refer to them.
Something like "redirect = Can be used to redirect all or some traffic to a site to compromise availability, integrity and confidentiality"
DOS = Resource Exhaustion = Can be used to exhaust bandwidth, cpu, io or other scarce resources by consuming too much of a resource either by causing the device to generate a lot of msgs or by sending directly towards device.

Operational and interop impact could be done the same way since those are mostly the same or come from a small set of impacts.

I see, but the threats are not included in the table, only the recommendations. Do you still feel like having specific definition for each threat would help, if we do not cite them from a common place, instead of having more flexibility with the text at each section?

You state in at least one spot that many stacks ignore an type/code pair but some other type/codes commonly ignored don't have that statement.

That would be a gap to fix. Which specific type/codes are currently commonly ignored but it is not mentioned in the corresponding section?

Thanks again!

-- Carlos.


(coffee != sleep) & (!coffee == sleep)
 Donald.Smith@qwest.com<mailto:Donald.Smith@qwest.com>
________________________________
From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] On Behalf Of Fernando Gont [fernando@gont.com.ar]
Sent: Monday, January 23, 2012 1:27 PM
To: Carlos Pignataro
Cc: 'opsec@ietf.org'
Subject: Re: [OPSEC] Fwd: New Version Notification for draft-gont-opsec-ip-options-filtering-01

Hi, Carlos,

Is there anything that still need to be addressed in the document?
(modulo nits and the quick fixes you highlighted in your last e-mail)?

Thanks,
Fernando




On 01/23/2012 03:12 PM, Carlos Pignataro wrote:

> On 12/16/2011 9:38 PM, Fernando Gont wrote:
>> Hi, Carlos,
>>
>> My apologies for the delay in my response. Please find my comments inline...
>>
>> On 06/15/2011 01:01 PM, Carlos Pignataro wrote:
>>> In a way, the comment behind my comment was that if today optioned
>>> packets are already mostly blocked/filtered out, the value of a
>>> per-option analysis decreases.
>>>
>>> Dan Wing was kind enough to run his experiment with existing options (as
>>> opposed to unknown options), with these results:
>>>
>>> Without any IP options:
>>> # grep open normal-nop.out | wc
>>>      486    2430   29901
>>
>> Sorry, what does each of the columns stand for?
>>
>
> This is the standard output of `wc` (word count), where the columns are
> number of lines, words, and characters, respectively. Only the first
> column is meaningful here (wc -l), and the important piece was that you
> get only a 3.29% success when using known options.
>
> Without any IP options:
> # grep open normal-nop.out | wc
>      486    2430   29901
>      ^^^
> with just NOP, NOP, NOP, EOL: // --ip-options \x01\x01\x01\x00
> # grep open ip-options-nop.out | wc
>       16      80    1099
>       ^^
> And 16 is a 3.29% of 486.
>
> [BTW: the script is at <http://www.employees.org/~dwing/ipoptions/>]
>
>>
>>
>>> I am not aware of papers with more scientific analysis of success rates
>>> with existing options. But:
>>>
>>> --->8---
>>>      Data seems to indicate that there is a current widespread
>>>      practice of blocking IPv4 optioned packets. There are various
>>>      plausible approaches to minimize the potential negative effects
>>>      of IPv4 optioned packets while allowing some options semantics.
>>>      One approach is to allow for specific options that are expected
>>>      or needed, and a default deny. A different approach is to deny
>>>      unneeded options and a default allow. Yet a third option is to
>>>      allow for end-to-end semantics by ignoring options and treating
>>>      packets as unoptioned while in transit. The current state tends
>>>      to support the first or third approaches as more realistic.
>>> --->8---
>>
>> I've added this (verbatim) to the intro, and have also added a pointer
>> to Medina's paper.
>>
>
> Ack -- Thanks!
>
>>
>>>>> 2. It assumes that devices (i.e., routers) have the capability to filter
>>>>> IP optioned packets with the per-option-value granularity. This might
>>>>> not generally be the case.
>>>
>>> I think this point should also be clarified.
>>
>> Done in the intro (right bellow the text you suggested above):
>>
>> --- cut here ---
>> We also note that while this document provides advice on a "per IP
>> option type", not all devices may provide functionality to filter IP
>> packets on a "per IP option type". Additionally, even in cases in which
>> such functionality is provided, the operator might want to specify a
>> filtering policy with a coarser granularity (rather than on a "per IP
>> option type" granularity), as indicated above.
>> ---- cut here ---
>>
>
> Thanks.
>
>>
>>>> I disagree with this assessment. The document assesses the impact of
>>>> filtering different options. If you're fine with the impact of filtering
>>>> all ip-optioned packets, then you don't need to filter at the
>>>> granularity of per-option-type.
>>>
>>> I guess what I was thinking is that an operator could think "what do I
>>> lose if I block this option" and do that exercise for every option, or
>>> "what do I gain by allowing", and this is where the (apparent) current
>>> practice has a role in deciding this.
>>
>> I think this is addressed by the text that you've provided?
>>
>
> I think so, I will re-read it too.
>
>>
>>>>> Additionally,
>>>>>
>>>>> 4. There may be more than "filter" versus "not-filter" options. Some
>>>>> platforms support ignoring IP options (i.e., acting as if an IP Optioned
>>>>> packet did not have options), and that is a potential recommendation.
>>>>
>>>> IIRC, this is already mentioned in the document.
>>>>
>>>
>>> I could not find it. Could you please point to the specific para?
>>>
>>> I think this is quite important because I think this is another practice
>>> often seen as the best option.
>>
>> You were right -- it wasn't there. I have added this to the intro:
>>
>> ---- cut here ----
>> Finally, in scenarios in which processing of IP options by intermediate
>> systems is not required, a widespread approach is to simply ignore IP
>> options, and processs the corresponding packets as if they do not
>> contain any IP options.
>> --- cut here ---
>>
>
> Thanks -- note a typo, s/processs/process/;
>
>>
>>>>> The first sentence of Section 3, "Router manufacturers tend to do IP
>>>>> option processing on the main processor, rather than on line cards",
>>>>> speaks to specific router distributed architecture, and I think it might
>>>>> be oversimplifying the current state.
>>>>
>>>> Proposed change?
>>>
>>> http://tools.ietf.org/html/rfc6192#section-1
>>>
>>>    Modern router architecture design maintains a strict separation of
>>>    forwarding and router control plane hardware and software.  The
>>>
>>> There are possible things like ICMP generation and IP option processing
>>> on general use processors in Line Cards, as opposed to LC forwarding
>>> ASICs. It is a punt to a slower path. But not necessarily a punt to the
>>> RP -- there may not be "main processor" but "main processors" depending
>>> on the context, and abstracting from actual architectures helps the
>>> document be more time invariant.
>>
>> How about changing the text to:
>> "Router manufacturers tend to do IP option processing in slower path.
>                                                           ^"a"
>> Unless special care is taken, this represents Denial of Service (DoS)
>                                                ^ "a potential"
>> risk, as there is potential for overwhelming the router with option
>       ^^^^^^^^^^^^^^^^^^^^^^^
>       I'd remove this and add "if protective measures are not taken".
>> processing."
>> ?
>>
>
> Looks good, modulo quick comments.
>
>>
>>>>> For EOO and NOOP, the advise is to:
>>>>>
>>>>>    No security issues are known for this option, other than the general
>>>>>    security implications of IP options discussed in Section 2.
>>>>>
>>>>> But I think that the general implications are the most important part of
>>>>> this document but are minimal.
>>>>
>>>> hence?
>>>
>>> Well, Section 2 is the default gateway for general implications
>>> applicable to all options but IMHO inadequately covers that subject. To
>>> be more precise, it does not cover it.
>>
>> Can you specify what (exactly) you're referring to, so that I can
>> improve the document in this respect?
>>
>
> The text says "general security implications of IP options discussed in
> Section 2", but there are no security implications discussed in S2.
>
>>
>>
>>> Section 2 does not have general security implications of IP options. It
>>> seems to contain a guide as to what options are (semantics and syntax)
>>> but not security implications.
>>
>> I've changed the ref to the one about the processing requirements.
>> Things can be improved from there.
>>
>> P.S.: I've submitted a rev of the document, since it had expired. It is
>> available at:
>> <http://www.ietf.org/id/draft-gont-opsec-ip-options-filtering-02.txt>.
>> Please take a look and see if any of the issues raised in this e-mail
>> still needs to be addressed. (It still need to work on other feedback
>> you provided in other e-mails).
>>
>> Thanks!
>>
>> Best regards,
>
> Sounds good.
>
> Thanks,
>
> -- Carlos.
>


--
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@si6networks.com
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

________________________________
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.


--Apple-Mail=_0235BF91-097C-48A0-8265-E7E999361188-- --Apple-Mail=_8D95D764-6328-435C-BE04-01775B33D13B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk9bkyIACgkQtfDPGTp3USzdkwCgrNxBzs57r8rVYqnjAPTrPJm+ EggAnR5VuO9ZBS5p/iG/KnbjGBqTgnTo =drU8 -----END PGP SIGNATURE----- --Apple-Mail=_8D95D764-6328-435C-BE04-01775B33D13B-- From cpignata@cisco.com Sat Mar 10 10:06:17 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFDF21F8516 for ; Sat, 10 Mar 2012 10:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0jgMIjtjJtA for ; Sat, 10 Mar 2012 10:06:15 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 61C7721F84F7 for ; Sat, 10 Mar 2012 10:06:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=cpignata@cisco.com; l=15391; q=dns/txt; s=iport; t=1331402768; x=1332612368; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=HavKbgsSdwi1yYfV2uPyJCrrpfFNOFHQd9vqubPZ6WE=; b=Zh7syIYUZQQiy2PkrZmm2TNxH8snqzIXJG0N6TBnFdr5RKLuXleQTDxy TI6dRlFTTZLvb2cP+kqjbaDrfgvYHzGYYFIbc3Hgf9/CMJwKp4jSIk4JI U8NWUGurtUIW/Ftit1xgkurN5yJ6atCQxmMhvi4QMbNkxtAm4EdnIEpOr Q=; X-Files: signature.asc : 203 X-IronPort-AV: E=Sophos;i="4.73,563,1325462400"; d="asc'?scan'208,217";a="65379160" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 10 Mar 2012 18:06:08 +0000 Received: from rtp-cpignata-89110.cisco.com (rtp-cpignata-89110.cisco.com [10.117.115.59]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2AI67DR024375; Sat, 10 Mar 2012 18:06:07 GMT Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_B2A2B08E-F763-4A56-9E3A-735348F2C518"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Carlos Pignataro In-Reply-To: <00c901ccf0e0$bf376180$3da62480$@com> Date: Sat, 10 Mar 2012 13:06:06 -0500 Message-Id: References: <20120217155754.14815.93144.idtracker@ietfa.amsl.com> <00c901ccf0e0$bf376180$3da62480$@com> To: Panos Kampanakis (pkampana) X-Mailer: Apple Mail (2.1257) Cc: opsec@ietf.org, Fernando Gont Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 18:06:17 -0000 --Apple-Mail=_B2A2B08E-F763-4A56-9E3A-735348F2C518 Content-Type: multipart/alternative; boundary="Apple-Mail=_3419C262-D48D-4E5E-9324-7FECC41BE651" --Apple-Mail=_3419C262-D48D-4E5E-9324-7FECC41BE651 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hello, Panos, Thanks for the feedback, please see inline. On Feb 21, 2012, at 4:35 PM, Panos Kampanakis (pkampana) wrote: > Hello, >=20 > Since this was revived (seems significantly changed with plenty of = edits to > follow), here are my initial comments. >=20 >=20 > - In "2. Internet Control Message Protocol version 4 (ICMP)" maybe it = would > be worth to clarify the table. That it refers to the actions devices = need to > take when generating, forwarding or receive such traffic. >=20 I thought this was clear, how would you improve for clarity? > Also "Depr" keyword is not clear what it means. For traffic generated = it > means you are not supposed to generate it. But when you are receiving, = does > it mean you should not allow the packet? >=20 Good point. I think this should be (is) explained in each section since = the table is only a summary. > Also I am not sure about the "ICMPv4-unreach", "ICMPv4-redirect" and > "ICMPv4-parameter" that are shown as N/A. The various codes for each = are > covered in the sebsequenct options per ICMP type. So, they represent a > superset of the various options. So, I am not sure they need to be in = the > table. Or maybe then can be in there just to group their options = together. >=20 >=20 They are not aggregated because different codes for a given type do not = have the same common recommendation. > - There is a difference between Router and Firewall traffic = processing. It > seems the document mostly speaks about recommendations on how to = process > ICMP with routers. Maybe you want to clarify if the document addresses = just > routers of network devices in general. And if the scope includes = firewalls, > the recommendations especially for ICMP generation will need to be > clarified. >=20 >=20 When would they differ? I think we should refer to general network = elements, no? > - In "2.1.1.4.3. Threats" it seems rate limiting doesn't address the > "connection-reset attacks". Maybe you want to make it clear or propose = other > mitigations. > You might also want to explicitly say that it should not be = rate-limited or > blocked. >=20 > - In 2.1.1.5.4. maybe you want to mention the impact of breaking PMTU, > especially in VPN setups. >=20 We should probably find an RFC to cite, because we can go into a = rat-hole describing this impact. >=20 > - In 2.1.1.7.3 and 2.1.1.9.3 don't you want to deny the deprecated = message > and not rate-limit? >=20 >=20 We should clarify the behavior for deprecated. > - In 2.1.1.10.3 and 2.1.1.11.3 "May reveal filtering policies" is not > mitigated. You may want to mention the deny for transient traffic. >=20 > - In 2.1.1.12.3 and 2.1.1.13.2 "May reveal routing policies" is not > mitigated. You may want to mention the deny for transient traffic. >=20 > - In most Threats section rate limiting is mentioned. But blocking = transient > traffic is not mentioned to mitigate threats even though it is in the = tables > as deny. >=20 > - 2.1.3.1.3, 2.1.3.2.3 and 2.1.3.3.3 don't discuss mitigations, rate > limiting or blocking >=20 Sorry I do not understand these. >=20 > - Recommendations like inspection statefully or blocking broadcast > destinations (smurf) are not addressed in 2.2.1.1.3 and 3.2.1.2.3 = (ICMPv6) >=20 >=20 But those are more specifics than the recommendations for the ICMP = themselves. I am not sure it would make sense to describe every = combination (multicast, ttl, etc) > - 2.2.4.1 are deprecated messages. Should routers generate them or = drop? > Depr in the table doesn't show if I receive an information echo = request > wheat I should do as a router, for example. >=20 Good point. Same as above. >=20 > - Rare ICMPv4 message types 30 and 31 (rfc1475) could be mentioned >=20 > - IPv6 threats sections don't mention mitigations as in ICMP for IPv4 >=20 > - Many ICMPv6 messages are missing from the v6 section including = ICMPv6 RS, > RA, NS, ND. A list is here = http://www.iana.org/assignments/icmpv6-parameters >=20 >=20 Yes, there are still messages pending. Thanks again! -- Carlos. >=20 >=20 > Rgs, > Panos >=20 >=20 > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf = Of > internet-drafts@ietf.org > Sent: Friday, February 17, 2012 10:58 AM > To: i-d-announce@ietf.org > Cc: opsec@ietf.org > Subject: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt >=20 >=20 > 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. >=20 > Title : Recommendations for filtering ICMP messages > Author(s) : Fernando Gont > Guillermo Gont > Carlos Pignataro > Filename : draft-ietf-opsec-icmp-filtering-02.txt > Pages : 49 > Date : 2012-02-17 >=20 > This document document provides advice on the filtering of ICMPv4 = and > ICMPv6 messages. Additionaly, it discusses the operational and > interoperability implications of such filtering. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-opsec-icmp-filtering-02.txt= >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsec-icmp-filtering-02.txt >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 >=20 --Apple-Mail=_3419C262-D48D-4E5E-9324-7FECC41BE651 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Hello, Panos,

Thanks for the feedback, please see inline.

On Feb 21, 2012, at 4:35 PM, Panos Kampanakis (pkampana) wrote:

RE: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt

Hello,

Since this was revived (seems significantly changed with plenty of edits to
follow), here are my initial comments.


- In "2.  Internet Control Message Protocol version 4 (ICMP)" maybe it would
be worth to clarify the table. That it refers to the actions devices need to
take when generating, forwarding or receive such traffic.

I thought this was clear, how would you improve for clarity?

Also "Depr" keyword is not clear what it means. For traffic generated it
means you are not supposed to generate it. But when you are receiving, does
it mean you should not allow the packet?

Good point. I think this should be (is) explained in each section since the table is only a summary.

Also I am not sure about the "ICMPv4-unreach", "ICMPv4-redirect" and
"ICMPv4-parameter" that are shown as N/A. The various codes for each are
covered in the sebsequenct options per ICMP type. So, they represent a
superset of the various options. So, I am not sure they need to be in the
table. Or maybe then can be in there just to group their options together.

They are not aggregated because different codes for a given type do not have the same common recommendation.

- There is a difference between Router and Firewall traffic processing. It
seems the document mostly speaks about recommendations on how to process
ICMP with routers. Maybe you want to clarify if the document addresses just
routers of network devices in general. And if the scope includes firewalls,
the recommendations especially for ICMP generation will need to be
clarified.

When would they differ? I think we should refer to general network elements, no?

- In "2.1.1.4.3.  Threats" it seems rate limiting doesn't address the
"connection-reset attacks". Maybe you want to make it clear or propose other
mitigations.
You might also want to explicitly say that it should not be rate-limited or
blocked.

- In 2.1.1.5.4. maybe you want to mention the impact of breaking PMTU,
especially in VPN setups.

We should probably find an RFC to cite, because we can go into a rat-hole describing this impact.


- In 2.1.1.7.3 and 2.1.1.9.3 don't you want to deny the deprecated message
and not rate-limit?

We should clarify the behavior for deprecated.

- In 2.1.1.10.3 and 2.1.1.11.3 "May reveal filtering policies" is not
mitigated. You may want to mention the deny for transient traffic.

- In 2.1.1.12.3 and 2.1.1.13.2 "May reveal routing policies" is not
mitigated. You may want to mention the deny for transient traffic.

- In most Threats section rate limiting is mentioned. But blocking transient
traffic is not mentioned to mitigate threats even though it is in the tables
as deny.

- 2.1.3.1.3, 2.1.3.2.3 and 2.1.3.3.3 don't discuss mitigations, rate
limiting or blocking

Sorry I do not understand these.


- Recommendations like inspection statefully or blocking broadcast
destinations (smurf) are not addressed in 2.2.1.1.3 and 3.2.1.2.3 (ICMPv6)

But those are more specifics than the recommendations for the ICMP themselves. I am not sure it would make sense to describe every combination (multicast, ttl, etc)

- 2.2.4.1 are deprecated messages. Should routers generate them or drop?
Depr in the table doesn't show if I receive an information echo request
wheat I should do as a router, for example.

Good point. Same as above.


- Rare ICMPv4 message types 30 and 31 (rfc1475) could be mentioned

- IPv6 threats sections don't mention mitigations as in ICMP for IPv4

- Many ICMPv6 messages are missing from the v6 section including ICMPv6 RS,
RA, NS, ND. A list is here http://www.iana.org/assignments/icmpv6-parameters

Yes, there are still messages pending.

Thanks again!

-- Carlos.



Rgs,
Panos


-----Original Message-----
From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of
internet-drafts@ietf.org
Sent: Friday, February 17, 2012 10:58 AM
To: i-d-announce@ietf.org
Cc: opsec@ietf.org
Subject: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt


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           : Recommendations for filtering ICMP messages
        Author(s)       : Fernando Gont
                          Guillermo Gont
                          Carlos Pignataro
        Filename        : draft-ietf-opsec-icmp-filtering-02.txt
        Pages           : 49
        Date            : 2012-02-17

   This document document provides advice on the filtering of ICMPv4 and
   ICMPv6 messages.  Additionaly, it discusses the operational and
   interoperability implications of such filtering.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-opsec-icmp-filtering-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsec-icmp-filtering-02.txt

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec


--Apple-Mail=_3419C262-D48D-4E5E-9324-7FECC41BE651-- --Apple-Mail=_B2A2B08E-F763-4A56-9E3A-735348F2C518 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iEYEARECAAYFAk9bmA8ACgkQtfDPGTp3USx/0wCglGP5U5F+JIZjhXmSL/+MBHm3 GWQAoJFgeTg9pl4ZrKpe6vJF/9ZHT0/9 =pbjf -----END PGP SIGNATURE----- --Apple-Mail=_B2A2B08E-F763-4A56-9E3A-735348F2C518-- From fernando.gont.netbook.win@gmail.com Sun Mar 11 07:28:22 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4B921F86DF for ; Sun, 11 Mar 2012 07:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KA8WD1-elU6U for ; Sun, 11 Mar 2012 07:28:12 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 74FC821F86DB for ; Sun, 11 Mar 2012 07:28:12 -0700 (PDT) Received: by werb10 with SMTP id b10so3055812wer.31 for ; Sun, 11 Mar 2012 07:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=JAs1st6v0fPUom8BPZ0Uoa9eVuQ/Yptvb/mfeaJ3yRM=; b=ok7X7M60Cvhpg1YSRLdY71Fdv2adJzxCbsLK2jDaya/nneZbhBk5NOxKhGLmR84P5S sIXlBDMQe2QVPbvJ5JqjDfdMXhZgWnuWjhdE0TZF8ALv0CnXJ+iwxselWfXfOXbHfsAe Isvreiz6EF3+aJGKs0yOfMk3mBrs05X1IfQkrov7cGp/i3QK3ruU9eHx3mJwXJOPcWI9 4hsj4Ddiiaaloh5foHfa8U2Lv90j9vxRADCMhsua6qEgLwvckUcgGZMvplmFAp9ARSGi Lneh1FHvE+gyajfh+k/39qlxib+Tc4fbhHC9bXR1wggpYOrn/56wsc+QVKDvgkPtLonr M2pw== Received: by 10.180.79.231 with SMTP id m7mr19778750wix.11.1331476091675; Sun, 11 Mar 2012 07:28:11 -0700 (PDT) Received: from [10.76.98.13] ([94.116.0.164]) by mx.google.com with ESMTPS id be4sm43039400wib.8.2012.03.11.07.28.09 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 07:28:10 -0700 (PDT) Sender: Fernando Gont Message-ID: <4F5C97BD.6050501@gont.com.ar> Date: Sun, 11 Mar 2012 09:17:01 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Panos Kampanakis References: <20120217155754.14815.93144.idtracker@ietfa.amsl.com> <00c901ccf0e0$bf376180$3da62480$@com> In-Reply-To: <00c901ccf0e0$bf376180$3da62480$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Carlos Pignataro \(cpignata\)" , opsec@ietf.org Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 14:28:22 -0000 Hi, Panos, Please find my comments inline... On 02/21/2012 06:35 PM, Panos Kampanakis wrote: > - In "2. Internet Control Message Protocol version 4 (ICMP)" maybe it would > be worth to clarify the table. That it refers to the actions devices need to > take when generating, forwarding or receive such traffic. You mean including such a para in Section 2, before the actual table? -- If so, I've just done that. > Also "Depr" keyword is not clear what it means. For traffic generated it > means you are not supposed to generate it. But when you are receiving, does > it mean you should not allow the packet? Good point. I've fixed this ("Depr" was "moved" to the message type, and the "action" is now to "deny" them -- since they are deprecated). > Also I am not sure about the "ICMPv4-unreach", "ICMPv4-redirect" and > "ICMPv4-parameter" that are shown as N/A. The various codes for each are > covered in the sebsequenct options per ICMP type. So, they represent a > superset of the various options. So, I am not sure they need to be in the > table. Makes sense. -- I've removed them. > - There is a difference between Router and Firewall traffic processing. It > seems the document mostly speaks about recommendations on how to process > ICMP with routers. Maybe you want to clarify if the document addresses just > routers of network devices in general. And if the scope includes firewalls, > the recommendations especially for ICMP generation will need to be > clarified. This is kind of the similar issue that arised with the ip-options-filtering I-D. My take is that for routers, you block whatever is known to have security implications ("default allow"), while for firewalls, you block everything you have not explicitly allowed ("default deny"). I'd like others to weigh in about this one.... > > - In "2.1.1.4.3. Threats" it seems rate limiting doesn't address the > "connection-reset attacks". Maybe you want to make it clear or propose other > mitigations. Fixed. > You might also want to explicitly say that it should not be rate-limited or > blocked. NOt sure why... could you please clarify this one? > - In 2.1.1.5.4. maybe you want to mention the impact of breaking PMTU, > especially in VPN setups. I've addded a few commments about this. > - In 2.1.1.7.3 and 2.1.1.9.3 don't you want to deny the deprecated message > and not rate-limit? True. Done! > - In 2.1.1.10.3 and 2.1.1.11.3 "May reveal filtering policies" is not > mitigated. You may want to mention the deny for transient traffic. Agreed about the "not mitigated" thing... However, I'm not sure what you mean with the latter. > - 2.1.3.1.3, 2.1.3.2.3 and 2.1.3.3.3 don't discuss mitigations, rate > limiting or blocking Fixed! > - Recommendations like inspection statefully or blocking broadcast > destinations (smurf) are not addressed in 2.2.1.1.3 and 3.2.1.2.3 (ICMPv6) The problem with filtering broadcasted ICMPs is that it can only be achieved at the last hop. -- I've added a note about this. > - 2.2.4.1 are deprecated messages. Should routers generate them or drop? > Depr in the table doesn't show if I receive an information echo request > wheat I should do as a router, for example. I've fixed this. > - Many ICMPv6 messages are missing from the v6 section including ICMPv6 RS, > RA, NS, ND. A list is here http://www.iana.org/assignments/icmpv6-parameters Yes. These will be included in the next rev. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From fgont@si6networks.com Sun Mar 11 07:28:22 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4EC21F86DB for ; Sun, 11 Mar 2012 07:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DQpterSOHUJ for ; Sun, 11 Mar 2012 07:28:05 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id BCC9821F86D9 for ; Sun, 11 Mar 2012 07:28:04 -0700 (PDT) Received: from [94.116.0.164] (helo=[10.76.98.13]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S6jke-0000dV-HH; Sun, 11 Mar 2012 15:28:00 +0100 Message-ID: <4F5C8DA3.7030804@si6networks.com> Date: Sun, 11 Mar 2012 08:33:55 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Panos Kampanakis References: <4DB74CBD.2050003@gont.com.ar> <4DCCA138.2000908@cisco.com><4DD5F510.5060405@gont.com.ar> <4DF8D73F.7020803@cisco.com><4EEC00AD.8020702@gont.com.ar> <4F1DA31E.5080608@cisco.com><4F1DC29D.5050209@gont.com.ar> <4F1DC51F.8020901@cisco.com> <002f01ccf055$bfa352e0$3ee9f8a0$@com> In-Reply-To: <002f01ccf055$bfa352e0$3ee9f8a0$@com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "Carlos Pignataro \(cpignata\)" , opsec@ietf.org Subject: Re: [OPSEC] Fwd: New VersionNotification for draft-gont-opsec-ip-options-filtering-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 14:28:22 -0000 Hi, Panos, Thanks so much for your feedback! Please find my comments inline.... On 02/21/2012 02:00 AM, Panos Kampanakis wrote: > Hi Fernando, > > Comments: > - In 4.3.4, 4.4.4 and 4.5.4 it is not clear to me what you mean by > "Nevertheless, it should be > noted that it is virtually impossible to use such techniques due to > widespread filtering of the LSRR/SSSR/... option." It means that in practice you cannot do troubleshooting with LSRR/SSSR, because they are largeley filtered (i.e., packets containing such options are dropped). -- I've tweaked the text a bit, to make it more clear. > - In 4.14.5 it states "Because of the design of this option, with variable > syntax and > variable length, it is not practical to support specialized filtering > using the CIPSO information.". If we can block based on type 130 or 131, > it is not clear why blocking type 134 is not possible. By filtering we mean "inspecting the contents of the option", rather than "blocking/dropping". -- I understand that the current version of the I-D uses "filtering" in ambiguous ways -- this will be fixed in the next rev. > - "4.18. Other IP Options" says that the unknown options should be ignored. > Routing devices and hosts should ignore options that they don't understand. > but I believe when we are discussing filtering options, unknown options > should be dropped for the sake of security and to prevent exploitations of > flaws we are not yet aware of. The issue here is that such filtering would prevent deployment of future options. One might argue that routers should ignore them, while firewalls should drop them. (since from the firewall's perspective, the idea usually is "anything that is not explicitly allowed should be blocked"). I'd like others to weigh in... > > Suggestions: > - In section "2. IP Options" it seems going over the ip iption header would > be better exlained with an ascii diagram > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - > | Option Type | Opt Data Len | Option Data > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Done. > - In "3.1. Processing Requirements" it seems you are referring to router > architectures which could mean any L3 device. But later in the paragraph > only routers are mentioned. Maybe it would make more sense to refer to them > as network devices, as it could be other L3 devices that are performing the > routing function Not sure what you mean... "network devices" sounds a bit ambiguous... > - In "4.12.5 Advice" and 4.13.5 it is stated "Routers and firewalls..." > where in other .5 sections the advice was expressed in a different format > "Filter...". A minor inconsistency there. This will be fixed throughout the whole document. Thanks! > Nit: > - Paragraph "This is the IPv4-version of the IPv6 amplification attack that > was > widely publicized in 2007 [Biondi2007]. The only difference is > that the maximum length of the IPv4 header (and hence the LSRR > option) limits the amplification factor when compared to the IPv6 > counter-part." > seems to be incorrectly indented. It is meant to be a parenthetical note -- hence the indentation. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From internet-drafts@ietf.org Mon Mar 12 09:42:13 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1785921E8059; Mon, 12 Mar 2012 09:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8auXFQE7Ap1; Mon, 12 Mar 2012 09:42:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7494621E804F; Mon, 12 Mar 2012 09:42:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312164212.26830.40471.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 09:42:12 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-03.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:42:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for= IP Network Infrastructure Working Group of the IETF. Title : Recommendations for filtering ICMP messages Author(s) : Fernando Gont Guillermo Gont Carlos Pignataro Filename : draft-ietf-opsec-icmp-filtering-03.txt Pages : 48 Date : 2012-03-12 This document document provides advice on the filtering of ICMPv4 and ICMPv6 messages. Additionaly, it discusses the operational and interoperability implications of such filtering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsec-icmp-filtering-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-opsec-icmp-filtering-03.txt From Donald.Smith@CenturyLink.com Mon Mar 12 09:47:08 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3087E21F880E for ; Mon, 12 Mar 2012 09:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jtv1mOVQyCOQ for ; Mon, 12 Mar 2012 09:47:07 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id 93B6321F8821 for ; Mon, 12 Mar 2012 09:47:06 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id q2CGl3v2019409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2012 11:47:03 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 622631E004D; Mon, 12 Mar 2012 10:46:58 -0600 (MDT) Received: from suomp61i.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 2D3E81E0060; Mon, 12 Mar 2012 10:46:58 -0600 (MDT) Received: from suomp61i.qintra.com (localhost [127.0.0.1]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q2CGkvK1003744; Mon, 12 Mar 2012 11:46:57 -0500 (CDT) Received: from qtdenexhtm21.AD.QINTRA.COM (qtdenexhtm21.ad.qintra.com [151.119.91.230]) by suomp61i.qintra.com (8.14.4/8.14.4) with ESMTP id q2CGkrJK003631 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 12 Mar 2012 11:46:57 -0500 (CDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Mon, 12 Mar 2012 10:46:56 -0600 From: "Smith, Donald" To: "'Fernando Gont'" , "'Panos Kampanakis'" Date: Mon, 12 Mar 2012 10:46:55 -0600 Thread-Topic: [OPSEC] Fwd: New VersionNotification for draft-gont-opsec-ip-options-filtering-01 Thread-Index: Acz/kzuuneniPGD/StSIjDkeLmiZrAA2gv+g Message-ID: References: <4DB74CBD.2050003@gont.com.ar> <4DCCA138.2000908@cisco.com><4DD5F510.5060405@gont.com.ar> <4DF8D73F.7020803@cisco.com><4EEC00AD.8020702@gont.com.ar> <4F1DA31E.5080608@cisco.com><4F1DC29D.5050209@gont.com.ar> <4F1DC51F.8020901@cisco.com> <002f01ccf055$bfa352e0$3ee9f8a0$@com> <4F5C8DA3.7030804@si6networks.com> In-Reply-To: <4F5C8DA3.7030804@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'Carlos Pignataro \(cpignata\)'" , "'opsec@ietf.org'" Subject: Re: [OPSEC] Fwd: New VersionNotification for draft-gont-opsec-ip-options-filtering-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:47:08 -0000 When packets collide the controllers cease transmission AND wait a random t= ime before retransmission (mostly)! Donald.Smith@CenturyLink.com > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf > Of Fernando Gont > Sent: Sunday, March 11, 2012 5:34 AM > To: Panos Kampanakis > Cc: Carlos Pignataro (cpignata); opsec@ietf.org > Subject: Re: [OPSEC] Fwd: New VersionNotification for draft-gont-opsec- > ip-options-filtering-01 > > Hi, Panos, > > Thanks so much for your feedback! Please find my comments inline.... > > On 02/21/2012 02:00 AM, Panos Kampanakis wrote: > > Hi Fernando, > > > > Comments: > > - In 4.3.4, 4.4.4 and 4.5.4 it is not clear to me what you mean by > > "Nevertheless, it should be > > noted that it is virtually impossible to use such techniques due > to > > widespread filtering of the LSRR/SSSR/... option." > > It means that in practice you cannot do troubleshooting with LSRR/SSSR, > because they are largeley filtered (i.e., packets containing such > options are dropped). Most ISPs don't drop such packets but they do ignore them. The default on c= isco is to ignore and has been for a long while. Most Firewalls do drop such packets so from an enterprise POV dropping is p= robably the default while from an ISP pov ignoring is probably the default. > > -- I've tweaked the text a bit, to make it more clear. > > > > > - In 4.14.5 it states "Because of the design of this option, with > > variable syntax and > > variable length, it is not practical to support specialized > filtering > > using the CIPSO information.". If we can block based on type 130 > or > > 131, it is not clear why blocking type 134 is not possible. > > By filtering we mean "inspecting the contents of the option", rather > than "blocking/dropping". -- I understand that the current version of > the I-D uses "filtering" in ambiguous ways -- this will be fixed in the > next rev. > > > > - "4.18. Other IP Options" says that the unknown options should be > ignored. > > Routing devices and hosts should ignore options that they don't > understand. > > but I believe when we are discussing filtering options, unknown > > options should be dropped for the sake of security and to prevent > > exploitations of flaws we are not yet aware of. > > The issue here is that such filtering would prevent deployment of > future options. > > One might argue that routers should ignore them, while firewalls should > drop them. (since from the firewall's perspective, the idea usually is > "anything that is not explicitly allowed should be blocked"). > > I'd like others to weigh in... > > > > > > Suggestions: > > - In section "2. IP Options" it seems going over the ip iption > header > > would be better exlained with an ascii diagram > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - > > | Option Type | Opt Data Len | Option Data > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - > > Done. > > > > > - In "3.1. Processing Requirements" it seems you are referring to > > router architectures which could mean any L3 device. But later in the > > paragraph only routers are mentioned. Maybe it would make more sense > > to refer to them as network devices, as it could be other L3 devices > > that are performing the routing function > > Not sure what you mean... "network devices" sounds a bit ambiguous... > > > > - In "4.12.5 Advice" and 4.13.5 it is stated "Routers and > firewalls..." > > where in other .5 sections the advice was expressed in a different > > format "Filter...". A minor inconsistency there. > > This will be fixed throughout the whole document. Thanks! > > > > Nit: > > - Paragraph "This is the IPv4-version of the IPv6 amplification > attack > > that was > > widely publicized in 2007 [Biondi2007]. The only difference is > > that the maximum length of the IPv4 header (and hence the LSRR > > option) limits the amplification factor when compared to the > IPv6 > > counter-part." > > seems to be incorrectly indented. > > It is meant to be a parenthetical note -- hence the indentation. > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From Donald.Smith@CenturyLink.com Mon Mar 12 10:05:13 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F34921F8709 for ; Mon, 12 Mar 2012 10:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DQF2arWaWm1 for ; Mon, 12 Mar 2012 10:05:12 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id C1C8F21F876E for ; Mon, 12 Mar 2012 10:05:11 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by suomp64i.qwest.com (8.14.4/8.14.4) with ESMTP id q2CH5AE2004824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Mar 2012 12:05:10 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id 1C2BF1E0060; Mon, 12 Mar 2012 11:05:05 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id F04321E006A; Mon, 12 Mar 2012 11:05:04 -0600 (MDT) Received: from sudnp796.qintra.com (localhost [127.0.0.1]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q2CH54B7004179; Mon, 12 Mar 2012 11:05:04 -0600 (MDT) Received: from qtdenexhtm21.AD.QINTRA.COM (qtdenexhtm21.ad.qintra.com [151.119.91.230]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q2CH4khd003697 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL); Mon, 12 Mar 2012 11:05:04 -0600 (MDT) Received: from qtdenexmbm24.AD.QINTRA.COM ([151.119.91.226]) by qtdenexhtm21.AD.QINTRA.COM ([151.119.91.230]) with mapi; Mon, 12 Mar 2012 11:04:46 -0600 From: "Smith, Donald" To: "Smith, Donald" , "'Fernando Gont'" , "'Panos Kampanakis'" Date: Mon, 12 Mar 2012 11:04:44 -0600 Thread-Topic: [OPSEC] Fwd: New VersionNotification for draft-gont-opsec-ip-options-filtering-01 Thread-Index: Acz/kzuuneniPGD/StSIjDkeLmiZrAA2gv+gAAEiaiA= Message-ID: References: <4DB74CBD.2050003@gont.com.ar> <4DCCA138.2000908@cisco.com><4DD5F510.5060405@gont.com.ar> <4DF8D73F.7020803@cisco.com><4EEC00AD.8020702@gont.com.ar> <4F1DA31E.5080608@cisco.com><4F1DC29D.5050209@gont.com.ar> <4F1DC51F.8020901@cisco.com> <002f01ccf055$bfa352e0$3ee9f8a0$@com> <4F5C8DA3.7030804@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "'Carlos Pignataro \(cpignata\)'" , "'opsec@ietf.org'" Subject: Re: [OPSEC] Fwd: New VersionNotification for draft-gont-opsec-ip-options-filtering-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:05:13 -0000 I made several very similar comments back on 2/20 which I never saw a respo= nse to. For example I suggested Depr be removed/moved.... Here is the text of the original email from 2/20/12 I have read this in the past but it has changed enough to require that I re= ad it again a few times:) I like the concept and agree with most of what yo= u have. Legend is incomplete, Deny, Permit, Send and N/A are undefined. I realize t= hey are sort of self explanatory but it may help to define them. For exampl= e deny do you mean silent drop or reset or send icmp errors or ...? Deprecated options may still be in use so we may want to think about if we = want to add an "action" to that. Is it apparent that the filtering is for r= outers only or routers and hosts or routers and hosts and firewalls? Firewalls tend to block a lot more then routers. They also incorrect use ic= mp errors to block certain types of packets/protocols etc... For example ip= tables sends port unreachable error msgs for all reject's. That can be modi= fied but that is the default. Also the concept at edge of net, internal net etc... seem to be important b= ut not covered by the table which may be ok just pointing that out. So whil= e we might filter some packets out at the edge of the network we may allow = them internally. For example I wouldn't want a icmp redirect to come from o= utside my network but may allow it internally same for TOS/df bits. I would= n't want someone controlling which queue they get into on my routers but ma= y want to use TOS within my network. I am not sure I agree with all your recommendations in the table but that i= s going to require I read it a few times before making any suggestions. Threats could probably be defined somewhere in full then use a similar abbr= eviation as you have done in the table to refer to them. Something like "redirect =3D Can be used to redirect all or some traffic to= a site to compromise availability, integrity and confidentiality" DOS =3D Resource Exhaustion =3D Can be used to exhaust bandwidth, cpu, io o= r other scarce resources by consuming too much of a resource either by caus= ing the device to generate a lot of msgs or by sending directly towards dev= ice. Operational and interop impact could be done the same way since those are m= ostly the same or come from a small set of impacts. You state in at least one spot that many stacks ignore an type/code pair bu= t some other type/codes commonly ignored don't have that statement. When packets collide the controllers cease transmission AND wait a random t= ime before retransmission (mostly)! Donald.Smith@CenturyLink.com > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf > Of Smith, Donald > Sent: Monday, March 12, 2012 10:47 AM > To: 'Fernando Gont'; 'Panos Kampanakis' > Cc: 'Carlos Pignataro (cpignata)'; 'opsec@ietf.org' > Subject: Re: [OPSEC] Fwd: New VersionNotification for draft-gont-opsec- > ip-options-filtering-01 > > > > When packets collide the controllers cease transmission AND wait a > random time before retransmission (mostly)! > Donald.Smith@CenturyLink.com > > > > -----Original Message----- > > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On > Behalf > > Of Fernando Gont > > Sent: Sunday, March 11, 2012 5:34 AM > > To: Panos Kampanakis > > Cc: Carlos Pignataro (cpignata); opsec@ietf.org > > Subject: Re: [OPSEC] Fwd: New VersionNotification for > > draft-gont-opsec- > > ip-options-filtering-01 > > > > Hi, Panos, > > > > Thanks so much for your feedback! Please find my comments inline.... > > > > On 02/21/2012 02:00 AM, Panos Kampanakis wrote: > > > Hi Fernando, > > > > > > Comments: > > > - In 4.3.4, 4.4.4 and 4.5.4 it is not clear to me what you mean by > > > "Nevertheless, it should be > > > noted that it is virtually impossible to use such techniques due > > to > > > widespread filtering of the LSRR/SSSR/... option." > > > > It means that in practice you cannot do troubleshooting with > > LSRR/SSSR, because they are largeley filtered (i.e., packets > > containing such options are dropped). > > Most ISPs don't drop such packets but they do ignore them. The default > on cisco is to ignore and has been for a long while. > > Most Firewalls do drop such packets so from an enterprise POV dropping > is probably the default while from an ISP pov ignoring is probably the > default. > > > > > > -- I've tweaked the text a bit, to make it more clear. > > > > > > > > > - In 4.14.5 it states "Because of the design of this option, with > > > variable syntax and > > > variable length, it is not practical to support specialized > > filtering > > > using the CIPSO information.". If we can block based on type 130 > > or > > > 131, it is not clear why blocking type 134 is not possible. > > > > By filtering we mean "inspecting the contents of the option", rather > > than "blocking/dropping". -- I understand that the current version of > > the I-D uses "filtering" in ambiguous ways -- this will be fixed in > > the next rev. > > > > > > > - "4.18. Other IP Options" says that the unknown options should be > > ignored. > > > Routing devices and hosts should ignore options that they don't > > understand. > > > but I believe when we are discussing filtering options, unknown > > > options should be dropped for the sake of security and to prevent > > > exploitations of flaws we are not yet aware of. > > > > The issue here is that such filtering would prevent deployment of > > future options. > > > > One might argue that routers should ignore them, while firewalls > > should drop them. (since from the firewall's perspective, the idea > > usually is "anything that is not explicitly allowed should be > blocked"). > > > > I'd like others to weigh in... > > > > > > > > > > Suggestions: > > > - In section "2. IP Options" it seems going over the ip iption > > header > > > would be better exlained with an ascii diagram > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - > > > | Option Type | Opt Data Len | Option Data > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - > > > > Done. > > > > > > > > > - In "3.1. Processing Requirements" it seems you are referring to > > > router architectures which could mean any L3 device. But later in > > > the paragraph only routers are mentioned. Maybe it would make more > > > sense to refer to them as network devices, as it could be other L3 > > > devices that are performing the routing function > > > > Not sure what you mean... "network devices" sounds a bit ambiguous... > > > > > > > - In "4.12.5 Advice" and 4.13.5 it is stated "Routers and > > firewalls..." > > > where in other .5 sections the advice was expressed in a different > > > format "Filter...". A minor inconsistency there. > > > > This will be fixed throughout the whole document. Thanks! > > > > > > > Nit: > > > - Paragraph "This is the IPv4-version of the IPv6 amplification > > attack > > > that was > > > widely publicized in 2007 [Biondi2007]. The only difference > is > > > that the maximum length of the IPv4 header (and hence the > LSRR > > > option) limits the amplification factor when compared to the > > IPv6 > > > counter-part." > > > seems to be incorrectly indented. > > > > It is meant to be a parenthetical note -- hence the indentation. > > > > Thanks! > > > > Best regards, > > -- > > Fernando Gont > > SI6 Networks > > e-mail: fgont@si6networks.com > > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the > sender by reply e-mail and destroy all copies of the communication and > any attachments. > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec This communication is the property of CenturyLink and may contain confident= ial or privileged information. Unauthorized use of this communication is st= rictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From pkampana@cisco.com Mon Mar 12 19:51:35 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4223D21F8874 for ; Mon, 12 Mar 2012 19:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.061 X-Spam-Level: X-Spam-Status: No, score=-9.061 tagged_above=-999 required=5 tests=[AWL=1.538, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZuAP2AhMQWux for ; Mon, 12 Mar 2012 19:51:34 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 397E621F8871 for ; Mon, 12 Mar 2012 19:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=4840; q=dns/txt; s=iport; t=1331607094; x=1332816694; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=46yc2G4I497YWW4tk+ggBcMZTJJu5RipF5EBCR0MPao=; b=P7eqy/QacHGyphFkC11BvSLLrFUXg+aqfK2xxbonn8IXZcMHJd86eAS4 /ZoPYGaL3hrOZpRWDb6btRGTKIp3ZXDXWIaDiWFSYcaxi24w7gpAg/sDB W0WmegTSSKIIvz/Kg7Lt8+GcJlC6YeYtwddWRvPOrTltdJbByx6EtduOi Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALi1Xk+tJXG//2dsb2JhbABDpXWPaoEHggkBAQEDAQgKARUCED8FBwEDAgkPAgQBAQEnBxkIJQkIAQEEEwkCEwSHYwULnRcBnxWJRGwBBIY0BI1jkxSEeIJ/gTgBBAM X-IronPort-AV: E=Sophos;i="4.73,574,1325462400"; d="scan'208";a="65902406" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 13 Mar 2012 02:51:09 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2D2p8XK027003; Tue, 13 Mar 2012 02:51:08 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 21:51:08 -0500 Received: from WIN-ICH1QO6NCS6 ([10.116.63.178]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 21:51:08 -0500 Received: from WINICH1QO6NCS6 by WIN-ICH1QO6NCS6 (PGP Universal service); Mon, 12 Mar 2012 22:50:28 -0500 X-PGP-Universal: processed; by WIN-ICH1QO6NCS6 on Mon, 12 Mar 2012 22:50:28 -0500 From: "Panos Kampanakis" To: "'Fernando Gont'" References: <20120217155754.14815.93144.idtracker@ietfa.amsl.com> <00c901ccf0e0$bf376180$3da62480$@com> <4F5C97BD.6050501@gont.com.ar> In-Reply-To: <4F5C97BD.6050501@gont.com.ar> Date: Mon, 12 Mar 2012 22:50:25 -0400 Organization: Cisco Systems Inc. Message-ID: <003e01cd00c4$0b4195d0$21c4c170$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz/kza0et2q9jyRThe9SqPCFSBpuABLvYYA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Language: en-us X-OriginalArrivalTime: 13 Mar 2012 02:51:08.0193 (UTC) FILETIME=[240B6910:01CD00C4] Cc: "Carlos Pignataro \(cpignata\)" , opsec@ietf.org Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 02:51:35 -0000 Thanks for answering my questions Fernando. They make sense. I am not sure if this comment has come up in the past, but I Came across "RFC4890: Recommendations for Filtering ICMPv6 Messages in Firewalls". It seems section 4 of that has similarities with the IPv6 section in draft-ietf-opsec-icmp-filtering even though it doesn't follow the exact same format. One distinction between draft-ietf-opsec-icmp-filtering and 4890 is that it consolidates and summarizes v4 and v6 ICMP filtering. But are there any other reasons why a newly created draft describes information in another RFC without adding additional elements? I didn't see 4890 mentioned in draft-ietf-opsec-icmp-filtering. Should draft-ietf-opsec-icmp-filtering extend or update RFC4890? Panos -----Original Message----- From: Fernando Gont [mailto:fernando.gont.netbook.win@gmail.com] On Behalf Of Fernando Gont Sent: Sunday, March 11, 2012 8:17 AM To: Panos Kampanakis Cc: opsec@ietf.org; Carlos Pignataro (cpignata) Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-icmp-filtering-02.txt Hi, Panos, Please find my comments inline... On 02/21/2012 06:35 PM, Panos Kampanakis wrote: > - In "2. Internet Control Message Protocol version 4 (ICMP)" maybe it > would be worth to clarify the table. That it refers to the actions > devices need to take when generating, forwarding or receive such traffic. You mean including such a para in Section 2, before the actual table? -- If so, I've just done that. > Also "Depr" keyword is not clear what it means. For traffic generated > it means you are not supposed to generate it. But when you are > receiving, does it mean you should not allow the packet? Good point. I've fixed this ("Depr" was "moved" to the message type, and the "action" is now to "deny" them -- since they are deprecated). > Also I am not sure about the "ICMPv4-unreach", "ICMPv4-redirect" and > "ICMPv4-parameter" that are shown as N/A. The various codes for each > are covered in the sebsequenct options per ICMP type. So, they > represent a superset of the various options. So, I am not sure they > need to be in the table. Makes sense. -- I've removed them. > - There is a difference between Router and Firewall traffic > processing. It seems the document mostly speaks about recommendations > on how to process ICMP with routers. Maybe you want to clarify if the > document addresses just routers of network devices in general. And if > the scope includes firewalls, the recommendations especially for ICMP > generation will need to be clarified. This is kind of the similar issue that arised with the ip-options-filtering I-D. My take is that for routers, you block whatever is known to have security implications ("default allow"), while for firewalls, you block everything you have not explicitly allowed ("default deny"). I'd like others to weigh in about this one.... > > - In "2.1.1.4.3. Threats" it seems rate limiting doesn't address the > "connection-reset attacks". Maybe you want to make it clear or propose > other mitigations. Fixed. > You might also want to explicitly say that it should not be > rate-limited or blocked. NOt sure why... could you please clarify this one? > - In 2.1.1.5.4. maybe you want to mention the impact of breaking PMTU, > especially in VPN setups. I've addded a few commments about this. > - In 2.1.1.7.3 and 2.1.1.9.3 don't you want to deny the deprecated > message and not rate-limit? True. Done! > - In 2.1.1.10.3 and 2.1.1.11.3 "May reveal filtering policies" is not > mitigated. You may want to mention the deny for transient traffic. Agreed about the "not mitigated" thing... However, I'm not sure what you mean with the latter. > - 2.1.3.1.3, 2.1.3.2.3 and 2.1.3.3.3 don't discuss mitigations, rate > limiting or blocking Fixed! > - Recommendations like inspection statefully or blocking broadcast > destinations (smurf) are not addressed in 2.2.1.1.3 and 3.2.1.2.3 > (ICMPv6) The problem with filtering broadcasted ICMPs is that it can only be achieved at the last hop. -- I've added a note about this. > - 2.2.4.1 are deprecated messages. Should routers generate them or drop? > Depr in the table doesn't show if I receive an information echo > request wheat I should do as a router, for example. I've fixed this. > - Many ICMPv6 messages are missing from the v6 section including > ICMPv6 RS, RA, NS, ND. A list is here > http://www.iana.org/assignments/icmpv6-parameters Yes. These will be included in the next rev. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From gvandeve@cisco.com Tue Mar 20 03:36:54 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1907E21F8652 for ; Tue, 20 Mar 2012 03:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.519 X-Spam-Level: X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY-U1nKIJcL4 for ; Tue, 20 Mar 2012 03:36:53 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2A89B21F8637 for ; Tue, 20 Mar 2012 03:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=2909; q=dns/txt; s=iport; t=1332239813; x=1333449413; h=mime-version:subject:date:message-id:from:to; bh=smCD3TSYuPAM/f10W33k1iSgWfpvE1au9ie0dX6ccDY=; b=A0cguPZjSokiJ8twUEAdV7i39jUdAgp5I6J5y2ADZLDytIGn5rFXob/q BkmKlTzSo84r81FdGOO9IbA62ybCSpLc52h/2/kJKqMwjzWmOFrZO0L3e TsUx9XCEkUFJUwnF2HwD/u1scudGYanQwv/xpcF6WdlGLiIDMnzgkXYX6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAI1caE+Q/khR/2dsb2JhbABBgkarLIhagQeCCwEEEgEJEQNbAQweBhgHVwEEGwEZh2gLl2yBJ58njVyCP2MEpB6BaIJo X-IronPort-AV: E=Sophos;i="4.73,617,1325462400"; d="scan'208,217";a="68877520" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 20 Mar 2012 10:36:52 +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 q2KAaq0r019989 for ; Tue, 20 Mar 2012 10:36:52 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 11:36:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0685.5C83300B" Date: Tue, 20 Mar 2012 11:36:51 +0100 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC50723E649@XMB-AMS-102.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for IETF83 has been published thread-index: Ac0GhVw/MSzZmdGbRS2fcWcdtGWBUg== From: "Gunter Van de Velde (gvandeve)" To: X-OriginalArrivalTime: 20 Mar 2012 10:36:52.0027 (UTC) FILETIME=[5CC258B0:01CD0685] Subject: [OPSEC] Agenda for IETF83 has been published X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 10:36:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0685.5C83300B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please find the agenda @ http://www.ietf.org/proceedings/83/agenda/agenda-83-opsec.html =20 =20 Kindly be aware that OPSAWG has kindly donated 30 minutes of their slot for OPSEC discussion.=20 =20 G/ ------_=_NextPart_001_01CD0685.5C83300B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Please find the agenda @ = <= span lang=3DEN-US>http://www.ietf.org/proceedings/83/agenda/agenda-83-opsec.ht= ml

 

Kindly be aware that OPSAWG has = kindly donated 30 minutes of their slot for OPSEC discussion. =

 

G/

------_=_NextPart_001_01CD0685.5C83300B-- From pkampana@cisco.com Mon Mar 26 10:37:34 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE1221E80EE for ; Mon, 26 Mar 2012 10:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.268 X-Spam-Level: X-Spam-Status: No, score=-9.268 tagged_above=-999 required=5 tests=[AWL=1.330, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiOyLIkDY70B for ; Mon, 26 Mar 2012 10:37:33 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 04AEE21E80DC for ; Mon, 26 Mar 2012 10:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=4574; q=dns/txt; s=iport; t=1332783453; x=1333993053; h=from:to:references:in-reply-to:subject:date:message-id: mime-version; bh=Ra/g5+uGs1ZNx2koiCHB912qXTQPfZsJVGcMY5pbu48=; b=CO3QDMa8FWCkvhm3VJP3SkoJ5rXX17HGRprD7FJqAAW9KaHgZr1PSrun LWaRTbtkym8fazh9l1WomBJLtr3oJUgj4cMGRTrHUUoCOGs/ZhGghc91M bCTpdEU6e2cDThWCknc5fOyEX1jesgHuwwSRzN4s3kXfnrDMs1Pm2klbG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFABipcE+tJV2c/2dsb2JhbABDgk+lfo9ogQeCCQEBAQQICgEVAgNZAwIJDwIEAQEoBxktCQgBAQQBEgkCF4doC55ylwyRKASNapY7gWiDAw X-IronPort-AV: E=Sophos;i="4.73,652,1325462400"; d="scan'208,217";a="69505321" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 26 Mar 2012 17:37:32 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2QHbWXI019005 for ; Mon, 26 Mar 2012 17:37:32 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 12:37:32 -0500 Received: from WIN-ICH1QO6NCS6 ([64.102.220.197]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Mar 2012 12:37:32 -0500 Received: from WINICH1QO6NCS6 by WIN-ICH1QO6NCS6 (PGP Universal service); Mon, 26 Mar 2012 13:36:47 -0500 X-PGP-Universal: processed; by WIN-ICH1QO6NCS6 on Mon, 26 Mar 2012 13:36:47 -0500 From: "Panos Kampanakis" To: "Gunter Van de Velde \(gvandeve\)" , References: <5C99EC8C99D9BB45AC51D20DC2AD2DC50723E649@XMB-AMS-102.cisco.com> In-Reply-To: <5C99EC8C99D9BB45AC51D20DC2AD2DC50723E649@XMB-AMS-102.cisco.com> Date: Mon, 26 Mar 2012 13:36:46 -0400 Organization: Cisco Systems Inc. Message-ID: <00b801cd0b77$04789ec0$0d69dc40$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0GhVw/MSzZmdGbRS2fcWcdtGWBUgE8UQqw Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01CD0B55.7D66FEC0" Content-Language: en-us X-OriginalArrivalTime: 26 Mar 2012 17:37:32.0120 (UTC) FILETIME=[1F816580:01CD0B77] Subject: Re: [OPSEC] Agenda for IETF83 has been published X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 17:37:34 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00B9_01CD0B55.7D66FEC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thank you. Are there any remote attendance options? Panos From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de Velde (gvandeve) Sent: Tuesday, March 20, 2012 6:37 AM To: opsec@ietf.org Subject: [OPSEC] Agenda for IETF83 has been published Please find the agenda @ http://www.ietf.org/proceedings/83/agenda/agenda-83-opsec.html Kindly be aware that OPSAWG has kindly donated 30 minutes of their slot for OPSEC discussion. G/ ------=_NextPart_000_00B9_01CD0B55.7D66FEC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you.

 

Are there any remote = attendance options?

 

Panos

 

 

From:= = opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of = Gunter Van de Velde (gvandeve)
Sent: Tuesday, March 20, = 2012 6:37 AM
To: opsec@ietf.org
Subject: [OPSEC] = Agenda for IETF83 has been published

 

Please find = the agenda @ <= span = lang=3DEN-US>http://www.ietf.org/proceedings/83/agenda/agenda-83-opsec.ht= ml

 

Kindly be = aware that OPSAWG has kindly donated 30 minutes of their slot for OPSEC = discussion.

 

G/

------=_NextPart_000_00B9_01CD0B55.7D66FEC0-- From rbonica@juniper.net Mon Mar 26 22:29:55 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6761A21F85A5 for ; Mon, 26 Mar 2012 22:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.508 X-Spam-Level: X-Spam-Status: No, score=-106.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m543iahAKe9u for ; Mon, 26 Mar 2012 22:29:54 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0B96A21F85A4 for ; Mon, 26 Mar 2012 22:29:53 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT3FQUQ3C4lXr3VfwHf8uX+MCQDg3iCq/@postini.com; Mon, 26 Mar 2012 22:29:54 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 26 Mar 2012 22:29:42 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 26 Mar 2012 22:29:42 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 27 Mar 2012 01:29:41 -0400 From: Ronald Bonica To: "opsec@ietf.org" Date: Tue, 27 Mar 2012 01:29:39 -0400 Thread-Topic: A Tale of Two Drafts Thread-Index: Ac0L2prEJfiJp8/6TjKMl+XRD41gxQ== Message-ID: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 05:29:55 -0000 Folks, As part of a thought experiment, assume that the IETF were to publish both = of the following drafts: - draft-behringer-lla-only-00 - draft-baker-opsec-passive-ip-address An operator, attempting to comply with both recommendations, might configur= e an interior router with exactly two globally scoped IPv6 addresses. Both = addresses would be loopbacks. One address would accept inbound traffic but = would never be the source of an ICMP message. The second address would not = accept inbound traffic but would be the source of all ICMP messages. Is this what we want? If so, we should say so explicitly (in one draft or t= he other, or possibly by merging the drafts). -------------------------- Ron Bonica /speaking as individual contributor vcard: www.bonica.org/ron/ronbonica.vcf From fred@cisco.com Mon Mar 26 22:39:44 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1D721F8781 for ; Mon, 26 Mar 2012 22:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ6Vnbuynrwl for ; Mon, 26 Mar 2012 22:39:43 -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 35F0621F8773 for ; Mon, 26 Mar 2012 22:39:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2038; q=dns/txt; s=iport; t=1332826783; x=1334036383; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=CQKopHuxrTj8ir6+znE3GHRAM97g/wgGPemPhCFoq+s=; b=ez17vW8TNxomRkrRZlEC8mXw0N2kiSL6MfXBcHYkorClfU0BAVpx1yQs KxGPlpkIjLUlzk3D8jiIucKADolerYsTpuQER8heZVN4s/uQBUrncjrIO G6alK6RhdigaYT2V4gxcYmDTeygwKuXFiBshvRSFTZOLeKKxmHl9i9zbk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALVRcU+Q/khR/2dsb2JhbABEuEWBB4IJAQEBBBIBJz8QCw4KLlcGNYVvgXmaQZ8IkCxjBJVhhW+IVoFogmmBWg X-IronPort-AV: E=Sophos;i="4.73,655,1325462400"; d="scan'208";a="133430763" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2012 05:39:40 +0000 Received: from Freds-Computer.local (dhcp-10-55-91-69.cisco.com [10.55.91.69]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2R5ddjN017452; Tue, 27 Mar 2012 05:39:40 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 27 Mar 2012 07:39:40 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 27 Mar 2012 07:39:40 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> Date: Tue, 27 Mar 2012 07:39:23 +0200 Message-Id: <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 05:39:44 -0000 On Mar 27, 2012, at 7:29 AM, Ronald Bonica wrote: > Is this what we want? If so, we should say so explicitly (in one draft = or the other, or possibly by merging the drafts). Jason and I were talking later, and came up with an approach that might = make sense. The premise is that you buy that LLAs should be used for routing = (Michael's argument, which I agree with), that you like passive = addresses for the security purpose, and you want the network manager = responsible for the network to be able to traceroute and get active = addresses for his purposes. One approach to implementation would be for a service provider to = implement his network with even-odd pairs of subnet prefixes. "Even-Odd" = might be trivially understood to mean "pairs of subnets in which bit 63 = is zero in one and one in the other"; that is one implementation, but in = fact the magic bit could be any of the bits in the subnet part of the = address. If there is one major prefix for the network, that would mean = that each interface has three addresses - a link-local address for use = in routing, a passive address in the even subnet, and an active address = in the odd subnet. Under policy control, the responder might respond to = traceroute or other messages with the active address if the source = address of the datagram is permitted by some access list, and with the = passive address otherwise. The impact of doing so would be to enable the = administration to debug its own network easily while denying similar = access to folks outside the network. In this manner, the passive address = (which is included in the general prefix the network advertises in BGP), = passes Ingress Filtering checks, but an attack packet gets dropped as = soon as it enters the network, as it is forwarded to the network's = "covering" route, which is null routed. A similar implementation approach would take one /64 prefix, null route = it throughput the network, and use /128s from that for the passive IP = addresses. From evyncke@cisco.com Tue Mar 27 00:32:05 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B0621F84F1 for ; Tue, 27 Mar 2012 00:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.423 X-Spam-Level: X-Spam-Status: No, score=-10.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3tgOusfUbzib for ; Tue, 27 Mar 2012 00:32:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 63F4C21F84EF for ; Tue, 27 Mar 2012 00:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=1462; q=dns/txt; s=iport; t=1332833524; x=1334043124; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=Jt1ZpQS+DE4ijHl+y7lOlQJK5gjOIdNCHiUl0YZlwwM=; b=TmHNfvExZQAaul1goLgW1/KgciaCJsljU1re2SWHstoU8HDtt2xvSH8C fRdDEYjEKLBmkBiE94GLXydVJIr8cymgPJ+8g2uDJgRIvHonCUBY59hCy 2ex6LkxDFcknH+LFq9nmWCa0Fa4Ls+4d+NxU0jeV1/W+pWNog06td1zK4 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANhrcU+Q/khM/2dsb2JhbABEuEiBB4IJAQEBBAEBAQ8BHRklFwQCAQgOAwQBAQsGFwEGASYfCQgBAQQBEggBGYdoC5o8nxSQLGMEiCWcAYFogmk X-IronPort-AV: E=Sophos;i="4.73,655,1325462400"; d="scan'208";a="69407641" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 27 Mar 2012 07:32:02 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2R7W2vf004815; Tue, 27 Mar 2012 07:32:02 GMT Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Mar 2012 09:32:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Mar 2012 09:32:00 +0200 Message-ID: <317616CE96204D49B5A1811098BA895006E50B9E@XMB-AMS-110.cisco.com> In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [OPSEC] A Tale of Two Drafts Thread-Index: Ac0L2prEJfiJp8/6TjKMl+XRD41gxQAD8x9A References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> From: "Eric Vyncke (evyncke)" To: "Ronald Bonica" , X-OriginalArrivalTime: 27 Mar 2012 07:32:02.0366 (UTC) FILETIME=[B3B29DE0:01CD0BEB] Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 07:32:05 -0000 Indeed, the two I-D are indeed compatible (some co-authors have talked = together). Passive-IP could require some code change while LLA is more a = configuration thing. Hence, two I-D -=E9ric > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf = Of > Ronald Bonica > Sent: mardi 27 mars 2012 07:30 > To: opsec@ietf.org > Subject: [OPSEC] A Tale of Two Drafts >=20 > Folks, >=20 > As part of a thought experiment, assume that the IETF were to publish = both > of the following drafts: >=20 > - draft-behringer-lla-only-00 > - draft-baker-opsec-passive-ip-address >=20 > An operator, attempting to comply with both recommendations, might = configure > an interior router with exactly two globally scoped IPv6 addresses. = Both > addresses would be loopbacks. One address would accept inbound traffic = but > would never be the source of an ICMP message. The second address would = not > accept inbound traffic but would be the source of all ICMP messages. >=20 > Is this what we want? If so, we should say so explicitly (in one draft = or > the other, or possibly by merging the drafts). >=20 > -------------------------- > Ron Bonica > /speaking as individual contributor > vcard: www.bonica.org/ron/ronbonica.vcf >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From rbonica@juniper.net Tue Mar 27 03:06:05 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FF221E8133 for ; Tue, 27 Mar 2012 03:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.509 X-Spam-Level: X-Spam-Status: No, score=-106.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdAl4hYYqG0p for ; Tue, 27 Mar 2012 03:06:03 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB7921E8136 for ; Tue, 27 Mar 2012 03:06:03 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT3GRCpldTl+0wLDKoEaWodstn62XRCiC@postini.com; Tue, 27 Mar 2012 03:06:03 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 27 Mar 2012 03:05:49 -0700 Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by p-cldfe02-hq.jnpr.net (172.24.192.60) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 27 Mar 2012 03:05:49 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Tue, 27 Mar 2012 06:05:48 -0400 From: Ronald Bonica To: Fred Baker Date: Tue, 27 Mar 2012 06:05:47 -0400 Thread-Topic: [OPSEC] A Tale of Two Drafts Thread-Index: Ac0L3AOqQXfBx03ARkafwf7ynv5fuQAJNJLg Message-ID: <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> In-Reply-To: <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:06:05 -0000 Fred, In the proposal that you describe, does every interface on the router have = a globally scoped address or just the loopback? Ron > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Tuesday, March 27, 2012 7:39 AM > To: Ronald Bonica > Cc: opsec@ietf.org > Subject: Re: [OPSEC] A Tale of Two Drafts >=20 >=20 > On Mar 27, 2012, at 7:29 AM, Ronald Bonica wrote: > > Is this what we want? If so, we should say so explicitly (in one > draft or the other, or possibly by merging the drafts). >=20 > Jason and I were talking later, and came up with an approach that might > make sense. >=20 > The premise is that you buy that LLAs should be used for routing > (Michael's argument, which I agree with), that you like passive > addresses for the security purpose, and you want the network manager > responsible for the network to be able to traceroute and get active > addresses for his purposes. >=20 > One approach to implementation would be for a service provider to > implement his network with even-odd pairs of subnet prefixes. "Even- > Odd" might be trivially understood to mean "pairs of subnets in which > bit 63 is zero in one and one in the other"; that is one > implementation, but in fact the magic bit could be any of the bits in > the subnet part of the address. If there is one major prefix for the > network, that would mean that each interface has three addresses - a > link-local address for use in routing, a passive address in the even > subnet, and an active address in the odd subnet. Under policy control, > the responder might respond to traceroute or other messages with the > active address if the source address of the datagram is permitted by > some access list, and with the passive address otherwise. The impact of > doing so would be to enable the administration to debug its own network > easily while denying similar access to folks outside the network. In > this manner, the passive address (which is included in the general > prefix the network advertises in BGP), passes Ingress Filtering checks, > but an attack packet gets dropped as soon as it enters the network, as > it is forwarded to the network's "covering" route, which is null > routed. >=20 > A similar implementation approach would take one /64 prefix, null route > it throughput the network, and use /128s from that for the passive IP > addresses. From fred@cisco.com Tue Mar 27 04:24:14 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A901221E8167 for ; Tue, 27 Mar 2012 04:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.555 X-Spam-Level: X-Spam-Status: No, score=-110.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FohZ7V+1qs-R for ; Tue, 27 Mar 2012 04:24:12 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 374BF21E8150 for ; Tue, 27 Mar 2012 04:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=3467; q=dns/txt; s=iport; t=1332847452; x=1334057052; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=9NYThhO4bt8IQQ+DKXMWltYZswd3vs/p+ccCi7KVvvo=; b=lo1pQQr2KYKAdgQcIyPhAdkoFT19xFUcf3BCVTp8Fkki6Exa8ofqfpki lqnG0s9GDx2Bq25sKMpXnwbXECxz4A42IQMjpEVmAjLaQxkvWtV/cIkNa gHMM/t5ScHbeybJ4NYnIHDtBpFWF33OilMCaYfBet02cdHO55jBQufRYb c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAWicU+Q/khM/2dsb2JhbABEuD6BB4IJAQEBAwESASc/BQcECw4DBAEBAScHRgkIBhMihW+BdAWaW58VkCxjBJVhhW+IVoFogmmBWg X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="69435331" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 27 Mar 2012 11:24:10 +0000 Received: from dhcp-5155.meeting.ietf.org (dhcp-10-55-82-191.cisco.com [10.55.82.191]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2RBOAda032090; Tue, 27 Mar 2012 11:24:10 GMT Received: from [127.0.0.1] by dhcp-5155.meeting.ietf.org (PGP Universal service); Tue, 27 Mar 2012 13:24:10 +0200 X-PGP-Universal: processed; by dhcp-5155.meeting.ietf.org on Tue, 27 Mar 2012 13:24:10 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> Date: Tue, 27 Mar 2012 13:24:00 +0200 Message-Id: <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> To: Ronald Bonica X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:24:14 -0000 On Mar 27, 2012, at 12:05 PM, Ronald Bonica wrote: > Fred, >=20 > In the proposal that you describe, does every interface on the router = have a globally scoped address or just the loopback? The proposal actually doesn't require that choice - the attribute is on = addresses where the operator configures them. Michael's proposal says = "only the loopback interface", which in my view means that ICMP messages = would use the loopback address as a source and would therefore leave the = router open to attack (as would using an ACL - yes, the router can throw = away the messages, but its bandwidth and its CPU are expended doing so). = I would prefer to make the attack traffic unable to disrupt the router, = the address indicative of the interface (putting at least the passive = address on the interface if not the active address), and the passive = address (and the active) in ip6.arpa. However, if the operator prefers = to put the passive and/or active addresses on the loopback interface, = that's the operator's option. > Ron >=20 >=20 >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com] >> Sent: Tuesday, March 27, 2012 7:39 AM >> To: Ronald Bonica >> Cc: opsec@ietf.org >> Subject: Re: [OPSEC] A Tale of Two Drafts >>=20 >>=20 >> On Mar 27, 2012, at 7:29 AM, Ronald Bonica wrote: >>> Is this what we want? If so, we should say so explicitly (in one >> draft or the other, or possibly by merging the drafts). >>=20 >> Jason and I were talking later, and came up with an approach that = might >> make sense. >>=20 >> The premise is that you buy that LLAs should be used for routing >> (Michael's argument, which I agree with), that you like passive >> addresses for the security purpose, and you want the network manager >> responsible for the network to be able to traceroute and get active >> addresses for his purposes. >>=20 >> One approach to implementation would be for a service provider to >> implement his network with even-odd pairs of subnet prefixes. "Even- >> Odd" might be trivially understood to mean "pairs of subnets in which >> bit 63 is zero in one and one in the other"; that is one >> implementation, but in fact the magic bit could be any of the bits in >> the subnet part of the address. If there is one major prefix for the >> network, that would mean that each interface has three addresses - a >> link-local address for use in routing, a passive address in the even >> subnet, and an active address in the odd subnet. Under policy = control, >> the responder might respond to traceroute or other messages with the >> active address if the source address of the datagram is permitted by >> some access list, and with the passive address otherwise. The impact = of >> doing so would be to enable the administration to debug its own = network >> easily while denying similar access to folks outside the network. In >> this manner, the passive address (which is included in the general >> prefix the network advertises in BGP), passes Ingress Filtering = checks, >> but an attack packet gets dropped as soon as it enters the network, = as >> it is forwarded to the network's "covering" route, which is null >> routed. >>=20 >> A similar implementation approach would take one /64 prefix, null = route >> it throughput the network, and use /128s from that for the passive IP >> addresses. >=20 From robert@raszuk.net Tue Mar 27 05:10:44 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFCD21E819C for ; Tue, 27 Mar 2012 05:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0HzBgEDArg7 for ; Tue, 27 Mar 2012 05:10:43 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id D72FA21F89D5 for ; Tue, 27 Mar 2012 05:10:42 -0700 (PDT) Received: (qmail 3188 invoked by uid 399); 27 Mar 2012 12:10:41 -0000 Received: from unknown (HELO ?130.129.17.148?) (robert@raszuk.net@130.129.17.148) by mail1310.opentransfer.com with ESMTPAM; 27 Mar 2012 12:10:41 -0000 X-Originating-IP: 130.129.17.148 References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> In-Reply-To: <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> Mime-Version: 1.0 (iPad Mail 8L1) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8L1) From: Robert Raszuk Date: Tue, 27 Mar 2012 14:10:37 +0200 To: Fred Baker Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:10:44 -0000 Hi Fred, Let me restate my question asked at the mic.=20 How do I make an address with the attribute set reachable by my NOC and not b= y any other NOC ? One of the chairs reposned use ACL but as you say this in n= ot the point of your draft. Have you consider that your attribute could automatically recognize addresse= s in the IGP and not make given address as passive for icmp, ssh, smtp from t= hose sources ? Thx, R. On 27 mar 2012, at 13:24, Fred Baker wrote: >=20 > On Mar 27, 2012, at 12:05 PM, Ronald Bonica wrote: >=20 >> Fred, >>=20 >> In the proposal that you describe, does every interface on the router hav= e a globally scoped address or just the loopback? >=20 > The proposal actually doesn't require that choice - the attribute is on ad= dresses where the operator configures them. Michael's proposal says "only th= e loopback interface", which in my view means that ICMP messages would use t= he loopback address as a source and would therefore leave the router open to= attack (as would using an ACL - yes, the router can throw away the messages= , but its bandwidth and its CPU are expended doing so). I would prefer to ma= ke the attack traffic unable to disrupt the router, the address indicative o= f the interface (putting at least the passive address on the interface if no= t the active address), and the passive address (and the active) in ip6.arpa.= However, if the operator prefers to put the passive and/or active addresses= on the loopback interface, that's the operator's option. >=20 >> Ron >>=20 >>=20 >>> -----Original Message----- >>> From: Fred Baker [mailto:fred@cisco.com] >>> Sent: Tuesday, March 27, 2012 7:39 AM >>> To: Ronald Bonica >>> Cc: opsec@ietf.org >>> Subject: Re: [OPSEC] A Tale of Two Drafts >>>=20 >>>=20 >>> On Mar 27, 2012, at 7:29 AM, Ronald Bonica wrote: >>>> Is this what we want? If so, we should say so explicitly (in one >>> draft or the other, or possibly by merging the drafts). >>>=20 >>> Jason and I were talking later, and came up with an approach that might >>> make sense. >>>=20 >>> The premise is that you buy that LLAs should be used for routing >>> (Michael's argument, which I agree with), that you like passive >>> addresses for the security purpose, and you want the network manager >>> responsible for the network to be able to traceroute and get active >>> addresses for his purposes. >>>=20 >>> One approach to implementation would be for a service provider to >>> implement his network with even-odd pairs of subnet prefixes. "Even- >>> Odd" might be trivially understood to mean "pairs of subnets in which >>> bit 63 is zero in one and one in the other"; that is one >>> implementation, but in fact the magic bit could be any of the bits in >>> the subnet part of the address. If there is one major prefix for the >>> network, that would mean that each interface has three addresses - a >>> link-local address for use in routing, a passive address in the even >>> subnet, and an active address in the odd subnet. Under policy control, >>> the responder might respond to traceroute or other messages with the >>> active address if the source address of the datagram is permitted by >>> some access list, and with the passive address otherwise. The impact of >>> doing so would be to enable the administration to debug its own network >>> easily while denying similar access to folks outside the network. In >>> this manner, the passive address (which is included in the general >>> prefix the network advertises in BGP), passes Ingress Filtering checks, >>> but an attack packet gets dropped as soon as it enters the network, as >>> it is forwarded to the network's "covering" route, which is null >>> routed. >>>=20 >>> A similar implementation approach would take one /64 prefix, null route >>> it throughput the network, and use /128s from that for the passive IP >>> addresses. >>=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From joelja@bogus.com Tue Mar 27 05:20:10 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C89321F8888 for ; Tue, 27 Mar 2012 05:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIWKtWxJy0Gq for ; Tue, 27 Mar 2012 05:20:09 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBB121F8872 for ; Tue, 27 Mar 2012 05:20:09 -0700 (PDT) Received: from dhcp-5710.meeting.ietf.org (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q2RCK5Aj047448 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 27 Mar 2012 12:20:07 GMT (envelope-from joelja@bogus.com) Message-ID: <4F71B074.7080809@bogus.com> Date: Tue, 27 Mar 2012 14:20:04 +0200 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Robert Raszuk References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 27 Mar 2012 12:20:08 +0000 (UTC) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:20:10 -0000 On 3/27/12 14:10 , Robert Raszuk wrote: > Hi Fred, > > Let me restate my question asked at the mic. > > How do I make an address with the attribute set reachable by my NOC > and not by any other NOC ? One of the chairs reposned use ACL but as > you say this in not the point of your draft. > > Have you consider that your attribute could automatically recognize > addresses in the IGP and not make given address as passive for icmp, > ssh, smtp from those sources ? default and/or very large aggregates frequently appears in IGPs... > Thx, R. > > > > On 27 mar 2012, at 13:24, Fred Baker wrote: > >> >> On Mar 27, 2012, at 12:05 PM, Ronald Bonica wrote: >> >>> Fred, >>> >>> In the proposal that you describe, does every interface on the >>> router have a globally scoped address or just the loopback? >> >> The proposal actually doesn't require that choice - the attribute >> is on addresses where the operator configures them. Michael's >> proposal says "only the loopback interface", which in my view means >> that ICMP messages would use the loopback address as a source and >> would therefore leave the router open to attack (as would using an >> ACL - yes, the router can throw away the messages, but its >> bandwidth and its CPU are expended doing so). I would prefer to >> make the attack traffic unable to disrupt the router, the address >> indicative of the interface (putting at least the passive address >> on the interface if not the active address), and the passive >> address (and the active) in ip6.arpa. However, if the operator >> prefers to put the passive and/or active addresses on the loopback >> interface, that's the operator's option. >> >>> Ron >>> >>> >>>> -----Original Message----- From: Fred Baker >>>> [mailto:fred@cisco.com] Sent: Tuesday, March 27, 2012 7:39 AM >>>> To: Ronald Bonica Cc: opsec@ietf.org Subject: Re: [OPSEC] A >>>> Tale of Two Drafts >>>> >>>> >>>> On Mar 27, 2012, at 7:29 AM, Ronald Bonica wrote: >>>>> Is this what we want? If so, we should say so explicitly (in >>>>> one >>>> draft or the other, or possibly by merging the drafts). >>>> >>>> Jason and I were talking later, and came up with an approach >>>> that might make sense. >>>> >>>> The premise is that you buy that LLAs should be used for >>>> routing (Michael's argument, which I agree with), that you like >>>> passive addresses for the security purpose, and you want the >>>> network manager responsible for the network to be able to >>>> traceroute and get active addresses for his purposes. >>>> >>>> One approach to implementation would be for a service provider >>>> to implement his network with even-odd pairs of subnet >>>> prefixes. "Even- Odd" might be trivially understood to mean >>>> "pairs of subnets in which bit 63 is zero in one and one in the >>>> other"; that is one implementation, but in fact the magic bit >>>> could be any of the bits in the subnet part of the address. If >>>> there is one major prefix for the network, that would mean that >>>> each interface has three addresses - a link-local address for >>>> use in routing, a passive address in the even subnet, and an >>>> active address in the odd subnet. Under policy control, the >>>> responder might respond to traceroute or other messages with >>>> the active address if the source address of the datagram is >>>> permitted by some access list, and with the passive address >>>> otherwise. The impact of doing so would be to enable the >>>> administration to debug its own network easily while denying >>>> similar access to folks outside the network. In this manner, >>>> the passive address (which is included in the general prefix >>>> the network advertises in BGP), passes Ingress Filtering >>>> checks, but an attack packet gets dropped as soon as it enters >>>> the network, as it is forwarded to the network's "covering" >>>> route, which is null routed. >>>> >>>> A similar implementation approach would take one /64 prefix, >>>> null route it throughput the network, and use /128s from that >>>> for the passive IP addresses. >>> >> >> _______________________________________________ OPSEC mailing list >> OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec > _______________________________________________ OPSEC mailing list > OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec > From robert@raszuk.net Tue Mar 27 05:31:48 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C2E21F8949 for ; Tue, 27 Mar 2012 05:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2gCrlxStJhs for ; Tue, 27 Mar 2012 05:31:47 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 789A221F894B for ; Tue, 27 Mar 2012 05:31:47 -0700 (PDT) Received: (qmail 795 invoked by uid 399); 27 Mar 2012 12:31:46 -0000 Received: from unknown (HELO ?130.129.17.148?) (robert@raszuk.net@130.129.17.148) by mail1310.opentransfer.com with ESMTPAM; 27 Mar 2012 12:31:46 -0000 X-Originating-IP: 130.129.17.148 References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> <4F71B074.7080809@bogus.com> In-Reply-To: <4F71B074.7080809@bogus.com> Mime-Version: 1.0 (iPad Mail 8L1) Content-Type: text/plain; charset=us-ascii Message-Id: <09F0B7CA-EABD-4EDC-BB9A-1B45DC9357C2@raszuk.net> Content-Transfer-Encoding: 7bit X-Mailer: iPad Mail (8L1) From: Robert Raszuk Date: Tue, 27 Mar 2012 14:31:45 +0200 To: Joel jaeggli Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:31:48 -0000 You could use igp tagging and only permit tagged routes to be legitimate src. R. On 27 mar 2012, at 14:20, Joel jaeggli wrote: > On 3/27/12 14:10 , Robert Raszuk wrote: >> Hi Fred, >> >> Let me restate my question asked at the mic. >> >> How do I make an address with the attribute set reachable by my NOC >> and not by any other NOC ? One of the chairs reposned use ACL but as >> you say this in not the point of your draft. >> >> Have you consider that your attribute could automatically recognize >> addresses in the IGP and not make given address as passive for icmp, >> ssh, smtp from those sources ? > > default and/or very large aggregates frequently appears in IGPs... > >> Thx, R. >> >> >> >> On 27 mar 2012, at 13:24, Fred Baker wrote: >> >>> >>> On Mar 27, 2012, at 12:05 PM, Ronald Bonica wrote: >>> >>>> Fred, >>>> >>>> In the proposal that you describe, does every interface on the >>>> router have a globally scoped address or just the loopback? >>> >>> The proposal actually doesn't require that choice - the attribute >>> is on addresses where the operator configures them. Michael's >>> proposal says "only the loopback interface", which in my view means >>> that ICMP messages would use the loopback address as a source and >>> would therefore leave the router open to attack (as would using an >>> ACL - yes, the router can throw away the messages, but its >>> bandwidth and its CPU are expended doing so). I would prefer to >>> make the attack traffic unable to disrupt the router, the address >>> indicative of the interface (putting at least the passive address >>> on the interface if not the active address), and the passive >>> address (and the active) in ip6.arpa. However, if the operator >>> prefers to put the passive and/or active addresses on the loopback >>> interface, that's the operator's option. >>> >>>> Ron >>>> >>>> >>>>> -----Original Message----- From: Fred Baker >>>>> [mailto:fred@cisco.com] Sent: Tuesday, March 27, 2012 7:39 AM >>>>> To: Ronald Bonica Cc: opsec@ietf.org Subject: Re: [OPSEC] A >>>>> Tale of Two Drafts >>>>> >>>>> >>>>> On Mar 27, 2012, at 7:29 AM, Ronald Bonica wrote: >>>>>> Is this what we want? If so, we should say so explicitly (in >>>>>> one >>>>> draft or the other, or possibly by merging the drafts). >>>>> >>>>> Jason and I were talking later, and came up with an approach >>>>> that might make sense. >>>>> >>>>> The premise is that you buy that LLAs should be used for >>>>> routing (Michael's argument, which I agree with), that you like >>>>> passive addresses for the security purpose, and you want the >>>>> network manager responsible for the network to be able to >>>>> traceroute and get active addresses for his purposes. >>>>> >>>>> One approach to implementation would be for a service provider >>>>> to implement his network with even-odd pairs of subnet >>>>> prefixes. "Even- Odd" might be trivially understood to mean >>>>> "pairs of subnets in which bit 63 is zero in one and one in the >>>>> other"; that is one implementation, but in fact the magic bit >>>>> could be any of the bits in the subnet part of the address. If >>>>> there is one major prefix for the network, that would mean that >>>>> each interface has three addresses - a link-local address for >>>>> use in routing, a passive address in the even subnet, and an >>>>> active address in the odd subnet. Under policy control, the >>>>> responder might respond to traceroute or other messages with >>>>> the active address if the source address of the datagram is >>>>> permitted by some access list, and with the passive address >>>>> otherwise. The impact of doing so would be to enable the >>>>> administration to debug its own network easily while denying >>>>> similar access to folks outside the network. In this manner, >>>>> the passive address (which is included in the general prefix >>>>> the network advertises in BGP), passes Ingress Filtering >>>>> checks, but an attack packet gets dropped as soon as it enters >>>>> the network, as it is forwarded to the network's "covering" >>>>> route, which is null routed. >>>>> >>>>> A similar implementation approach would take one /64 prefix, >>>>> null route it throughput the network, and use /128s from that >>>>> for the passive IP addresses. >>>> >>> >>> _______________________________________________ OPSEC mailing list >>> OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec >> _______________________________________________ OPSEC mailing list >> OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec >> > From joelja@bogus.com Tue Mar 27 05:39:19 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADAE21E8158 for ; Tue, 27 Mar 2012 05:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qFYZrNbmHKs for ; Tue, 27 Mar 2012 05:39:18 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8661721E8087 for ; Tue, 27 Mar 2012 05:39:18 -0700 (PDT) Received: from dhcp-5710.meeting.ietf.org (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q2RCd8UA047777 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 27 Mar 2012 12:39:10 GMT (envelope-from joelja@bogus.com) Message-ID: <4F71B4EB.3060504@bogus.com> Date: Tue, 27 Mar 2012 14:39:07 +0200 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Robert Raszuk References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> <4F71B074.7080809@bogus.com> <09F0B7CA-EABD-4EDC-BB9A-1B45DC9357C2@raszuk.net> In-Reply-To: <09F0B7CA-EABD-4EDC-BB9A-1B45DC9357C2@raszuk.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 27 Mar 2012 12:39:11 +0000 (UTC) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:39:20 -0000 On 3/27/12 14:31 , Robert Raszuk wrote: > You could use igp tagging and only permit tagged routes to be legitimate src. indeed > R. > > On 27 mar 2012, at 14:20, Joel jaeggli wrote: > >> On 3/27/12 14:10 , Robert Raszuk wrote: >>> Hi Fred, >>> >>> Let me restate my question asked at the mic. >>> >>> How do I make an address with the attribute set reachable by my NOC >>> and not by any other NOC ? One of the chairs reposned use ACL but as >>> you say this in not the point of your draft. >>> >>> Have you consider that your attribute could automatically recognize >>> addresses in the IGP and not make given address as passive for icmp, >>> ssh, smtp from those sources ? >> >> default and/or very large aggregates frequently appears in IGPs... >> >>> Thx, R. >>> >>> >>> >>> On 27 mar 2012, at 13:24, Fred Baker wrote: >>> >>>> >>>> On Mar 27, 2012, at 12:05 PM, Ronald Bonica wrote: >>>> >>>>> Fred, >>>>> >>>>> In the proposal that you describe, does every interface on the >>>>> router have a globally scoped address or just the loopback? >>>> >>>> The proposal actually doesn't require that choice - the attribute >>>> is on addresses where the operator configures them. Michael's >>>> proposal says "only the loopback interface", which in my view means >>>> that ICMP messages would use the loopback address as a source and >>>> would therefore leave the router open to attack (as would using an >>>> ACL - yes, the router can throw away the messages, but its >>>> bandwidth and its CPU are expended doing so). I would prefer to >>>> make the attack traffic unable to disrupt the router, the address >>>> indicative of the interface (putting at least the passive address >>>> on the interface if not the active address), and the passive >>>> address (and the active) in ip6.arpa. However, if the operator >>>> prefers to put the passive and/or active addresses on the loopback >>>> interface, that's the operator's option. >>>> >>>>> Ron >>>>> >>>>> >>>>>> -----Original Message----- From: Fred Baker >>>>>> [mailto:fred@cisco.com] Sent: Tuesday, March 27, 2012 7:39 AM >>>>>> To: Ronald Bonica Cc: opsec@ietf.org Subject: Re: [OPSEC] A >>>>>> Tale of Two Drafts >>>>>> >>>>>> >>>>>> On Mar 27, 2012, at 7:29 AM, Ronald Bonica wrote: >>>>>>> Is this what we want? If so, we should say so explicitly (in >>>>>>> one >>>>>> draft or the other, or possibly by merging the drafts). >>>>>> >>>>>> Jason and I were talking later, and came up with an approach >>>>>> that might make sense. >>>>>> >>>>>> The premise is that you buy that LLAs should be used for >>>>>> routing (Michael's argument, which I agree with), that you like >>>>>> passive addresses for the security purpose, and you want the >>>>>> network manager responsible for the network to be able to >>>>>> traceroute and get active addresses for his purposes. >>>>>> >>>>>> One approach to implementation would be for a service provider >>>>>> to implement his network with even-odd pairs of subnet >>>>>> prefixes. "Even- Odd" might be trivially understood to mean >>>>>> "pairs of subnets in which bit 63 is zero in one and one in the >>>>>> other"; that is one implementation, but in fact the magic bit >>>>>> could be any of the bits in the subnet part of the address. If >>>>>> there is one major prefix for the network, that would mean that >>>>>> each interface has three addresses - a link-local address for >>>>>> use in routing, a passive address in the even subnet, and an >>>>>> active address in the odd subnet. Under policy control, the >>>>>> responder might respond to traceroute or other messages with >>>>>> the active address if the source address of the datagram is >>>>>> permitted by some access list, and with the passive address >>>>>> otherwise. The impact of doing so would be to enable the >>>>>> administration to debug its own network easily while denying >>>>>> similar access to folks outside the network. In this manner, >>>>>> the passive address (which is included in the general prefix >>>>>> the network advertises in BGP), passes Ingress Filtering >>>>>> checks, but an attack packet gets dropped as soon as it enters >>>>>> the network, as it is forwarded to the network's "covering" >>>>>> route, which is null routed. >>>>>> >>>>>> A similar implementation approach would take one /64 prefix, >>>>>> null route it throughput the network, and use /128s from that >>>>>> for the passive IP addresses. >>>>> >>>> >>>> _______________________________________________ OPSEC mailing list >>>> OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec >>> _______________________________________________ OPSEC mailing list >>> OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec >>> >> > From fred@cisco.com Tue Mar 27 05:49:55 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D033221F87CD for ; Tue, 27 Mar 2012 05:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2+5JO2cuZEU for ; Tue, 27 Mar 2012 05:49:55 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 481EC21E81CD for ; Tue, 27 Mar 2012 05:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5210; q=dns/txt; s=iport; t=1332852594; x=1334062194; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=8kTnnMTNQ3WyrcijjvNm6W9ElZck/cqVomfOLgq3xks=; b=kGqv8/vM0RepkO7nqyMQrFBI35HheUvMDBp9yKYtVyOV5QobM+Z1YzT+ TKclJPqow3Ny/m3ZF//HvAuOgMdmLNkr8NMqLMwWFQBtjjdwJ3rbEXU7s LGhaohEivqUXIzE17sUlFD7dw6+x3juY8VLulgT4frtuCdpt3i6KkFRVe E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAC23cU+Q/khM/2dsb2JhbAA6CrhBgQeCCQEBAQQSARQTPxALGC5XBjWFb4F5mmCfFIpehU5jBJVhhW+IVoFogmmBWg X-IronPort-AV: E=Sophos;i="4.73,656,1325462400"; d="scan'208";a="69446097" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 27 Mar 2012 12:49:53 +0000 Received: from dhcp-5155.meeting.ietf.org (dhcp-10-61-98-225.cisco.com [10.61.98.225]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2RCnqjN022379; Tue, 27 Mar 2012 12:49:52 GMT Received: from [127.0.0.1] by dhcp-5155.meeting.ietf.org (PGP Universal service); Tue, 27 Mar 2012 14:49:53 +0200 X-PGP-Universal: processed; by dhcp-5155.meeting.ietf.org on Tue, 27 Mar 2012 14:49:53 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Tue, 27 Mar 2012 14:49:39 +0200 Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> To: Robert Raszuk X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 12:49:56 -0000 On Mar 27, 2012, at 2:10 PM, Robert Raszuk wrote: > How do I make an address with the attribute set reachable by my NOC = and not by any other NOC ? One of the chairs reposned use ACL but as you = say this in not the point of your draft. >=20 > Have you consider that your attribute could automatically recognize = addresses in the IGP and not make given address as passive for icmp, = ssh, smtp from those sources ? Since we're restating things, I'll restate what I said earlier today in = this same thread. I get to it by editing the email you sent me... >>>> The premise is that you buy that LLAs should be used for routing >>>> (Michael's argument, which I agree with), that you like passive >>>> addresses for the security purpose, and you want the network = manager >>>> responsible for the network to be able to traceroute and get active >>>> addresses for his purposes. >>>>=20 >>>> One approach to implementation would be for a service provider to >>>> implement his network with even-odd pairs of subnet prefixes. = "Even- >>>> Odd" might be trivially understood to mean "pairs of subnets in = which >>>> bit 63 is zero in one and one in the other"; that is one >>>> implementation, but in fact the magic bit could be any of the bits = in >>>> the subnet part of the address. If there is one major prefix for = the >>>> network, that would mean that each interface has three addresses - = a >>>> link-local address for use in routing, a passive address in the = even >>>> subnet, and an active address in the odd subnet. Under policy = control, >>>> the responder might respond to traceroute or other messages with = the >>>> active address if the source address of the datagram is permitted = by >>>> some access list, and with the passive address otherwise. The = impact of >>>> doing so would be to enable the administration to debug its own = network >>>> easily while denying similar access to folks outside the network. = In >>>> this manner, the passive address (which is included in the general >>>> prefix the network advertises in BGP), passes Ingress Filtering = checks, >>>> but an attack packet gets dropped as soon as it enters the network, = as >>>> it is forwarded to the network's "covering" route, which is null >>>> routed. >>>>=20 >>>> A similar implementation approach would take one /64 prefix, null = route >>>> it throughput the network, and use /128s from that for the passive = IP >>>> addresses. Now, let me repeat with pictures. Note that, as I told Ron, I'm not = stuck on whether the interface a passive or active address is on is = physical or virtual, although I would (if I were implementing it) put = passive and perhaps active addresses on physical interfaces so that a = traceroute response can identify the interface in question. In this = example sketch, I will therefore talk about the physical interface, but = it could as easily be virtual with a corresponding loss of information. Presume that the domain in question is 2001:db8:1::/48, and the "other = domain" in question is 2001:db8:2::/48. Taking the second approach = above, presume that the prefix 2001:db8:1:ffff::/64 is used for all = passive addresses in the target domain. So now every physical interface. _.--------. ,-'' `--. ,-----. ,' `. ,' `. ,' `. ,' `. / \ / \ / 2001:db8:1::/48 \ / 2001:db8:2::/48 \ / \ ; : / \ ; : ; +-----+ +------+ Traceroute : ; +--------+ : | |Host | |Router|<---------------------- |Attacker| | | |Alice| |Bob | ---------------------->|Carol | | | +--+--+ +--+---+ TTL Exp /----------- +--------+ | : ---+--------+----- / ; : ; \ / / : ; \ / / : ; \ Null Route V / \ / \ 2001:db8:1:ffff::/64 / \ / `. ,' `. ,' `. ,' `. ,' `--. _.-' `-----' `--------'' Carol wants to DOS Alice's router, Bob, reseting a BGP connection, = consuming its bandwidth, or whatever (Carol could simply DOS Alice's = address determined from DNS; this approach doesn't address that = problem). She starts by doing a traceroute toward Carol to determine = Bob's address, followed by a flood toward Bob. The sequence of messages = is an ICMP Echo or UDP whatever with a certain TTL, resulting in an ICMP = TTL Expired, followed by the flood. In the model I am suggesting, since the address given to Carol is a null = routed address, Carol cannot use it to get a packet to Bob. Does that help?= From jared@puck.nether.net Tue Mar 27 06:32:50 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4960021F881B for ; Tue, 27 Mar 2012 06:32:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL+M0FkNi8TU for ; Tue, 27 Mar 2012 06:32:49 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id AE11221F8812 for ; Tue, 27 Mar 2012 06:32:49 -0700 (PDT) Received: from dhcp-506e.meeting.ietf.org (dhcp-506e.meeting.ietf.org [130.129.80.110]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q2RDV48x018885 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2012 09:31:06 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Jared Mauch In-Reply-To: Date: Tue, 27 Mar 2012 09:32:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <25C9CC3A-7443-46E7-8AC5-E48978197C1D@puck.nether.net> References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> To: Robert Raszuk X-Mailer: Apple Mail (2.1257) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 27 Mar 2012 09:31:06 -0400 (EDT) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:32:50 -0000 On Mar 27, 2012, at 8:10 AM, Robert Raszuk wrote: > Hi Fred, >=20 > Let me restate my question asked at the mic.=20 >=20 > How do I make an address with the attribute set reachable by my NOC = and not by any other NOC ? One of the chairs reposned use ACL but as you = say this in not the point of your draft. >=20 > Have you consider that your attribute could automatically recognize = addresses in the IGP and not make given address as passive for icmp, = ssh, smtp from those sources ? I'm still having trouble with the link-local drafts, but perhaps it's = just me=85 The principle of least-surprise for the operators of networks tells me = that the IPv6 access part should look similar to IPv4 part. While I can = run some aspects of my IPv4 network with 'ip unnumbered' this generally = is not the case. While IPv6 is unique in providing the link-local whereas IPv4 doesn't = have, the average consumer/operator is unlikely to employ this technique = as it increases the complexity in the network to solve a problem in IPv6 = [only] that could be solved with a common IPv4+IPv6 Control Plane = Policing Policy/capability. =20 Using a different tool to mitigate this risk in IPv4 vs IPv6 concerns me = in that it creates unnecessary complexity. - Jared= From robert@raszuk.net Tue Mar 27 06:34:14 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2729C21F895D for ; Tue, 27 Mar 2012 06:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFuzHhTf5rCd for ; Tue, 27 Mar 2012 06:34:13 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 1943821F8892 for ; Tue, 27 Mar 2012 06:34:13 -0700 (PDT) Received: (qmail 26070 invoked by uid 399); 27 Mar 2012 13:34:12 -0000 Received: from unknown (HELO ?130.129.17.148?) (robert@raszuk.net@130.129.17.148) by mail1310.opentransfer.com with ESMTPAM; 27 Mar 2012 13:34:12 -0000 X-Originating-IP: 130.129.17.148 References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8L1) Content-Type: text/plain; charset=us-ascii Message-Id: <1F64A02D-7895-424C-970C-343A38955F49@raszuk.net> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (8L1) From: Robert Raszuk Date: Tue, 27 Mar 2012 15:34:11 +0200 To: Fred Baker Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:34:14 -0000 X-List-Received-Date: Tue, 27 Mar 2012 13:34:14 -0000 Thx Fred. I was suggesting to avoid "some acl" to be configured and maintained on all= routers but rather then that tag sources in ones igp which are authorized t= o get proper response from network elements.=20 That way your knob can be fully automated yet ease operational aspects. Btw is this not applicable to ipv4 also ? Many thx, R. On 27 mar 2012, at 14:49, Fred Baker wrote: >=20 > On Mar 27, 2012, at 2:10 PM, Robert Raszuk wrote: >> How do I make an address with the attribute set reachable by my NOC and n= ot by any other NOC ? One of the chairs reposned use ACL but as you say this= in not the point of your draft. >>=20 >> Have you consider that your attribute could automatically recognize addre= sses in the IGP and not make given address as passive for icmp, ssh, smtp fr= om those sources ? >=20 > Since we're restating things, I'll restate what I said earlier today in th= is same thread. I get to it by editing the email you sent me... >=20 >>>>> The premise is that you buy that LLAs should be used for routing >>>>> (Michael's argument, which I agree with), that you like passive >>>>> addresses for the security purpose, and you want the network manager >>>>> responsible for the network to be able to traceroute and get active >>>>> addresses for his purposes. >>>>>=20 >>>>> One approach to implementation would be for a service provider to >>>>> implement his network with even-odd pairs of subnet prefixes. "Even- >>>>> Odd" might be trivially understood to mean "pairs of subnets in which >>>>> bit 63 is zero in one and one in the other"; that is one >>>>> implementation, but in fact the magic bit could be any of the bits in >>>>> the subnet part of the address. If there is one major prefix for the >>>>> network, that would mean that each interface has three addresses - a >>>>> link-local address for use in routing, a passive address in the even >>>>> subnet, and an active address in the odd subnet. Under policy control,= >>>>> the responder might respond to traceroute or other messages with the >>>>> active address if the source address of the datagram is permitted by >>>>> some access list, and with the passive address otherwise. The impact o= f >>>>> doing so would be to enable the administration to debug its own networ= k >>>>> easily while denying similar access to folks outside the network. In >>>>> this manner, the passive address (which is included in the general >>>>> prefix the network advertises in BGP), passes Ingress Filtering checks= , >>>>> but an attack packet gets dropped as soon as it enters the network, as= >>>>> it is forwarded to the network's "covering" route, which is null >>>>> routed. >>>>>=20 >>>>> A similar implementation approach would take one /64 prefix, null rout= e >>>>> it throughput the network, and use /128s from that for the passive IP >>>>> addresses. >=20 > Now, let me repeat with pictures. Note that, as I told Ron, I'm not stuck o= n whether the interface a passive or active address is on is physical or vir= tual, although I would (if I were implementing it) put passive and perhaps a= ctive addresses on physical interfaces so that a traceroute response can ide= ntify the interface in question. In this example sketch, I will therefore ta= lk about the physical interface, but it could as easily be virtual with a co= rresponding loss of information. >=20 > Presume that the domain in question is 2001:db8:1::/48, and the "other dom= ain" in question is 2001:db8:2::/48. Taking the second approach above, presu= me that the prefix 2001:db8:1:ffff::/64 is used for all passive addresses in= the target domain. So now every physical interface. >=20 > _.--------. > ,-'' `--. ,-----. > ,' `. ,' `. > ,' `. ,' `. > / \ / \ > / 2001:db8:1::/48 \ / 2001:db8:2::/48 \ > / \ ; : > / \ ; : > ; +-----+ +------+ Traceroute : ; +--------+ : > | |Host | |Router|<---------------------- |Attacker| | > | |Alice| |Bob | ---------------------->|Carol | | > | +--+--+ +--+---+ TTL Exp /----------- +--------+ | > : ---+--------+----- / ; : ; > \ / / : ; > \ / / : ; > \ Null Route V / \ / > \ 2001:db8:1:ffff::/64 / \ / > `. ,' `. ,' > `. ,' `. ,' > `--. _.-' `-----' > `--------'' >=20 > Carol wants to DOS Alice's router, Bob, reseting a BGP connection, consumi= ng its bandwidth, or whatever (Carol could simply DOS Alice's address determ= ined from DNS; this approach doesn't address that problem). She starts by do= ing a traceroute toward Carol to determine Bob's address, followed by a floo= d toward Bob. The sequence of messages is an ICMP Echo or UDP whatever with a= certain TTL, resulting in an ICMP TTL Expired, followed by the flood. >=20 > In the model I am suggesting, since the address given to Carol is a null r= outed address, Carol cannot use it to get a packet to Bob. >=20 > Does that help? From jared@puck.nether.net Tue Mar 27 06:37:18 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 586AF21F8897 for ; Tue, 27 Mar 2012 06:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 79Vi3H7vi488 for ; Tue, 27 Mar 2012 06:37:17 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 1169821F888E for ; Tue, 27 Mar 2012 06:37:13 -0700 (PDT) Received: from dhcp-506e.meeting.ietf.org (dhcp-506e.meeting.ietf.org [130.129.80.110]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q2RDZUom019965 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Mar 2012 09:35:31 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <1F64A02D-7895-424C-970C-343A38955F49@raszuk.net> Date: Tue, 27 Mar 2012 09:37:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> <1F64A02D-7895-424C-970C-343A38955F49@raszuk.net> To: Robert Raszuk X-Mailer: Apple Mail (2.1257) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Tue, 27 Mar 2012 09:35:32 -0400 (EDT) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:37:18 -0000 On Mar 27, 2012, at 9:34 AM, Robert Raszuk wrote: > Btw is this not applicable to ipv4 also ? My thought is a solution should be comparable in deployment regardless = of the bit length of the address. - Jared= From gert@space.net Tue Mar 27 06:37:24 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E22B21F88A4 for ; Tue, 27 Mar 2012 06:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTuIKWQOeJwL for ; Tue, 27 Mar 2012 06:37:24 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1868021F8896 for ; Tue, 27 Mar 2012 06:37:23 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E28E5F8A74 for ; Tue, 27 Mar 2012 15:37:21 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id C5BB1F8A4C for ; Tue, 27 Mar 2012 15:37:21 +0200 (CEST) Received: (qmail 82781 invoked by uid 1007); 27 Mar 2012 15:37:21 +0200 Date: Tue, 27 Mar 2012 15:37:21 +0200 From: Gert Doering To: Jared Mauch Message-ID: <20120327133721.GX84425@Space.Net> References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> <25C9CC3A-7443-46E7-8AC5-E48978197C1D@puck.nether.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25C9CC3A-7443-46E7-8AC5-E48978197C1D@puck.nether.net> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:37:24 -0000 Hi, On Tue, Mar 27, 2012 at 09:32:43AM -0400, Jared Mauch wrote: > I'm still having trouble with the link-local drafts, but perhaps it's just me? It's me as well... I'm so old-fashioned, I like ping, mtr, traceroute, and all the good stuff that helps me figure out where in my neighbouring networks my happy packets turn unhappy. And yes, I know about the shortcomings, but it's still better than "take it away completely, because there are never any problems in my network!". But I can see that people do like the approach, and I'm fine with that, as long the final document doesn't tell people "this is the only proper way to run your network!" but properly documents reasons for doing so, and shortcomings. Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From joelja@bogus.com Tue Mar 27 06:45:45 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 139EE21E819E for ; Tue, 27 Mar 2012 06:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IExNdo1+Exxh for ; Tue, 27 Mar 2012 06:45:44 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 6232521E8089 for ; Tue, 27 Mar 2012 06:45:44 -0700 (PDT) Received: from dhcp-5710.meeting.ietf.org (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q2RDjfuo049122 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Tue, 27 Mar 2012 13:45:43 GMT (envelope-from joelja@bogus.com) Message-ID: <4F71C483.2090908@bogus.com> Date: Tue, 27 Mar 2012 15:45:39 +0200 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Jared Mauch References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> <25C9CC3A-7443-46E7-8AC5-E48978197C1D@puck.nether.net> In-Reply-To: <25C9CC3A-7443-46E7-8AC5-E48978197C1D@puck.nether.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 27 Mar 2012 13:45:44 +0000 (UTC) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:45:45 -0000 On 3/27/12 15:32 , Jared Mauch wrote: > Using a different tool to mitigate this risk in IPv4 vs IPv6 concerns me in that it creates unnecessary complexity. For mitigation of ND issues one can use /127s for point-to-point so obscuring the link for ND attack avoidance applies to larger subnets but not the case where you'd get away with ip unumbered ip ipv4. l2 nets with a number routers or exchange fabrics have somewhat more complex issues. > - Jared > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > From fred@cisco.com Tue Mar 27 06:55:44 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2577621F8A2B for ; Tue, 27 Mar 2012 06:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.558 X-Spam-Level: X-Spam-Status: No, score=-110.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWcn5Ul7U9ch for ; Tue, 27 Mar 2012 06:55:43 -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 15F6121F8A28 for ; Tue, 27 Mar 2012 06:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=218; q=dns/txt; s=iport; t=1332856543; x=1334066143; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=IS641SdHKpyoe1Rmqec2p5NQC03s3GOOKlSGH4QKU9I=; b=hUGBJ3Q6leU3lzuDSzH6i0bcIixh0cS2svZAcDd0AlI6uRVMQpMHGnls mRwjQgkXfVKmWADnUbtap/iquSEaRzni7OZGyaslX66p3G1oIh+NWLrmz 8NRXvOTxpu6ERtfdlJ7txnjn3HcEitwRabfomDep/jD850Xqj4Ozu5M8M g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEfGcU+Q/khM/2dsb2JhbABDuEqBB4IJAQEBAwESASc/BQsLRlcGNYdjBZ5yly2QLGMElWGFb4hWgWiCaQ X-IronPort-AV: E=Sophos;i="4.73,657,1325462400"; d="scan'208";a="133492150" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2012 13:55:42 +0000 Received: from dhcp-5155.meeting.ietf.org (ams3-vpn-dhcp4280.cisco.com [10.61.80.183]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2RDtf3J004370; Tue, 27 Mar 2012 13:55:42 GMT Received: from [127.0.0.1] by dhcp-5155.meeting.ietf.org (PGP Universal service); Tue, 27 Mar 2012 15:55:42 +0200 X-PGP-Universal: processed; by dhcp-5155.meeting.ietf.org on Tue, 27 Mar 2012 15:55:42 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <1F64A02D-7895-424C-970C-343A38955F49@raszuk.net> Date: Tue, 27 Mar 2012 15:55:26 +0200 Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> <1F64A02D-7895-424C-970C-343A38955F49@raszuk.net> To: Robert Raszuk X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 13:55:44 -0000 On Mar 27, 2012, at 3:34 PM, Robert Raszuk wrote: > Btw is this not applicable to ipv4 also ? I'm mostly thinking about IPv6. But I tried pretty hard to word the = draft so that it could be applied to IPv4.= From warren@kumari.net Thu Mar 29 08:14:15 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F7221E80DF for ; Thu, 29 Mar 2012 08:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.217 X-Spam-Level: X-Spam-Status: No, score=-105.217 tagged_above=-999 required=5 tests=[AWL=1.383, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUqxrhXgBVNq for ; Thu, 29 Mar 2012 08:14:14 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 50F6921E80AC for ; Thu, 29 Mar 2012 08:14:06 -0700 (PDT) Received: from dhcp-25ae.meeting.ietf.org (dhcp-25ae.meeting.ietf.org [130.129.37.174]) by vimes.kumari.net (Postfix) with ESMTPSA id 5D25A1B40ABC for ; Thu, 29 Mar 2012 11:14:06 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Mar 2012 17:14:05 +0200 Message-Id: <70091649-25DF-467D-B6B9-193549BE954F@kumari.net> To: opsec@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [OPSEC] Minutes have been posted... X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 15:14:15 -0000 Hi there, Thanks to Carlos Pignataro for taking such detailed minutes, they have = been posted. W -- Don't be impressed with unintelligible stuff said condescendingly. -- Radia Perlman. From jared@puck.nether.net Thu Mar 29 09:17:42 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA2421F8809 for ; Thu, 29 Mar 2012 09:17:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EB4PgI0vufCv for ; Thu, 29 Mar 2012 09:17:42 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 2C86221F87D4 for ; Thu, 29 Mar 2012 09:17:42 -0700 (PDT) Received: from dhcp-506e.meeting.ietf.org (dhcp-506e.meeting.ietf.org [130.129.80.110]) (authenticated bits=0) by puck.nether.net (8.14.4/8.14.4) with ESMTP id q2TGFw8Z002487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 29 Mar 2012 12:15:59 -0400 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: <20120327133721.GX84425@Space.Net> Date: Thu, 29 Mar 2012 12:17:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <13205C286662DE4387D9AF3AC30EF456D76917AF26@EMBX01-WF.jnpr.net> <8D601B33-F606-40B3-A041-9488446F2096@cisco.com> <13205C286662DE4387D9AF3AC30EF456D76917AF4F@EMBX01-WF.jnpr.net> <9FB29D88-388A-4F04-A674-179642F01428@cisco.com> <25C9CC3A-7443-46E7-8AC5-E48978197C1D@puck.nether.net> <20120327133721.GX84425@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1257) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (puck.nether.net [204.42.254.5]); Thu, 29 Mar 2012 12:16:00 -0400 (EDT) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] A Tale of Two Drafts X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:17:42 -0000 Previously on OPSEC: On Mar 27, 2012, at 9:37 AM, Gert Doering wrote: > I'm so old-fashioned, I like ping, mtr, traceroute, and all the good > stuff that helps me figure out where in my neighbouring networks my > happy packets turn unhappy. And yes, I know about the shortcomings,=20= > but it's still better than "take it away completely, because there > are never any problems in my network!". >=20 > But I can see that people do like the approach, and I'm fine with = that, > as long the final document doesn't tell people "this is the only = proper=20 > way to run your network!" but properly documents reasons for doing so, > and shortcomings. [Today in v6ops] There were some comments today at the mic which I personally take as = key. An operator (I didn't catch who, sorry if you're not on here) = spoke about their experience using link-local in their IPv6 deployment. = The experience resulted in it becoming removed from their environment. ---- Personally I would like to see a well-defined problem statement. In the = current form, I don't feel this can be something that moves in the BCP = direction and will likely be a footnote/blip in the history of early = IPv6 days. - Jared= From ietf@meetecho.com Mon Mar 26 06:03:32 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 827F521F853A for ; Mon, 26 Mar 2012 06:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bvw+dDw4FIwx for ; Mon, 26 Mar 2012 06:03:32 -0700 (PDT) Received: from smtplq04.aruba.it (smtplqs-out21.aruba.it [62.149.158.61]) by ietfa.amsl.com (Postfix) with SMTP id 60ECC21F850D for ; Mon, 26 Mar 2012 06:03:31 -0700 (PDT) Received: (qmail 27574 invoked by uid 89); 26 Mar 2012 13:03:08 -0000 Received: from unknown (HELO smtp8.aruba.it) (62.149.158.228) by smtplq04.aruba.it with SMTP; 26 Mar 2012 13:03:08 -0000 Received: (qmail 18631 invoked by uid 89); 26 Mar 2012 13:03:08 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp8.ad.aruba.it with SMTP; 26 Mar 2012 13:03:08 -0000 Message-ID: <4F70690D.2070407@meetecho.com> Date: Mon, 26 Mar 2012 15:03:09 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120312 Thunderbird/11.0 MIME-Version: 1.0 To: opsec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp8.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N X-Mailman-Approved-At: Fri, 30 Mar 2012 08:46:31 -0700 Subject: [OPSEC] Meetecho support for OPSEC WG meeting session X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 13:03:32 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Monday's OPSEC WG meeting session. Access to the on-line session (including audio and video streams) is available: http://www.meetecho.com/ietf83/opsec The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com