From pkampana@cisco.com Sun Sep 2 15:33:56 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 262C421F84F6 for ; Sun, 2 Sep 2012 15:33:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDL8O9XYkc6M for ; Sun, 2 Sep 2012 15:33:55 -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 5E7D921F84CF for ; Sun, 2 Sep 2012 15:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=2958; q=dns/txt; s=iport; t=1346625235; x=1347834835; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JOPxPxWiBoELUIUujBqAp080BAowlI++zYnb8fAb5U0=; b=ksFDavmkgsD1dY8VcF3cv1wwy2v0aHhGo1DxQOgXKwq6fI0Ban6GLeSf gR6x8bfgEjepvN2C3rg0R5QGLgTgb5G6ZPgyqVtxneeJxP3WM8hTZ1GAZ zurNirzqCOQh7SIbdnesLkMFI9mjA4LJPpWxc+rZH9Zgk86vuGoKenXlC E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAbeQ1CtJV2Z/2dsb2JhbABFuyGBB4IgAQEBBAEBAQ8BCh00CwwEAgEIEQMBAQELFAkHJwsUCQgCBAENBQgBGYdrC5p3nw+LDYZDYAOWbY0fgWeCYw X-IronPort-AV: E=Sophos;i="4.80,356,1344211200"; d="scan'208";a="117631339" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 02 Sep 2012 22:33:54 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q82MXsxa015896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 2 Sep 2012 22:33:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0298.004; Sun, 2 Sep 2012 17:33:54 -0500 From: "Panos Kampanakis (pkampana)" To: "Gunter Van de Velde (gvandeve)" , Fernando Gont , "'opsec@ietf.org'" Thread-Topic: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt Thread-Index: AQHNf4/xMv9kGvkdN06QC8tsypxtgZd3td1A Date: Sun, 2 Sep 2012 22:33:53 +0000 Message-ID: <1C9F17D1873AFA47A969C4DD98F98A75062E81@xmb-rcd-x10.cisco.com> References: <20120821111757.8846.20372.idtracker@ietfa.amsl.com> <50336EBA.1080105@gont.com.ar> <67832B1175062E48926BF3CB27C49B24077F08@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B24077F08@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.63.179] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19158.001 x-tm-as-result: No--39.527400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: opsec chairs Subject: Re: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-nets-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, 02 Sep 2012 22:33:56 -0000 1. Yes. I had provided my thouhgts/feedback for Fernando in previous emails= . 2. Informational (had expressed my reasoning in previous thread) Panos -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of G= unter Van de Velde (gvandeve) Sent: Tuesday, August 21, 2012 7:27 AM To: Fernando Gont; 'opsec@ietf.org' Cc: opsec chairs Subject: Re: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-= nets-02.txt With this note the OPSEC chairs would like to probe for WG adoption. During the cause of events and discussion on the WG mailing list, this docu= ment has been seen as valuable for the WG to adopt as work item. 2 questions need to be addressed: 1. Please find 2 weeks to provide feedback on this draft. Please say yes/no= on WG adoption.=20 2. Should this be BCP or Informational track G/ -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of F= ernando Gont Sent: 21 August 2012 13:19 To: 'opsec@ietf.org' Cc: opsec chairs Subject: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-nets= -02.txt Folks, FYI, I have posted a new rev of the aforementioned I-D, which is meant to a= ddress the feedback I have received so far. This version should be ready for the formal wg call for adoption-. Thanks! Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt Date: Tue, 21 Aug 2012 04:17:57 -0700 From: internet-drafts@ietf.org To: fernando@gont.com.ar A new version of I-D, draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.tx= t has been successfully submitted by Fernando Gont and posted to the IETF rep= ository. Filename: draft-gont-opsec-ipv6-implications-on-ipv4-nets Revision: 02 Title: Security Implications of IPv6 on IPv4 Networks Creation date: 2012-08-21 WG ID: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-implications-on-i= pv4-nets-02.txt Status: http://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-implications-on-ipv4-= nets Htmlized: http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets-= 02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-opsec-ipv6-implications-on-ip= v4-nets-02 Abstract: This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. The IETF Secretariat _______________________________________________ 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 internet-drafts@ietf.org Tue Sep 4 02:43: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 7E1F321F8665; Tue, 4 Sep 2012 02:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.682 X-Spam-Level: X-Spam-Status: No, score=-101.682 tagged_above=-999 required=5 tests=[AWL=0.917, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmGY6sRO7Fsi; Tue, 4 Sep 2012 02:43:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E46B21F8652; Tue, 4 Sep 2012 02:43:17 -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.34 Message-ID: <20120904094317.23219.42206.idtracker@ietfa.amsl.com> Date: Tue, 04 Sep 2012 02:43:17 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-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, 04 Sep 2012 09:43:17 -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 : Security Implications of IPv6 on IPv4 Networks Author(s) : Fernando Gont Filename : draft-ietf-opsec-ipv6-implications-on-ipv4-nets-00.txt Pages : 18 Date : 2012-09-04 Abstract: This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4= -nets There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-= 00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Donald.Smith@CenturyLink.com Tue Sep 4 08:36: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 76BD621F8569 for ; Tue, 4 Sep 2012 08:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XszhER1SqEHI for ; Tue, 4 Sep 2012 08:36:17 -0700 (PDT) Received: from suomp64i.qwest.com (suomp64i.qwest.com [155.70.16.237]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9521F865B for ; Tue, 4 Sep 2012 08:36:14 -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 q84Fa971013768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Sep 2012 10:36:09 -0500 (CDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id C08831E0085; Tue, 4 Sep 2012 09:35:51 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id A48761E0077; Tue, 4 Sep 2012 09:35:51 -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 q84FZpup022953; Tue, 4 Sep 2012 09:35:51 -0600 (MDT) Received: from vddcwhubex501.ctl.intranet (vddcwhubex501.qintra.com [151.119.128.28]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id q84FZoHj022950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Sep 2012 09:35:51 -0600 (MDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex501.ctl.intranet ([2002:9777:801c::9777:801c]) with mapi id 14.02.0283.003; Tue, 4 Sep 2012 09:35:51 -0600 From: "Smith, Donald" To: "Panos Kampanakis (pkampana)" , "Gunter Van de Velde (gvandeve)" , Fernando Gont , "'opsec@ietf.org'" Thread-Topic: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt Thread-Index: AQHNiVsNK9DruBX4gUS6BA5D5X09uJd6UImp Date: Tue, 4 Sep 2012 15:35:50 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D0A1C71E4@PDDCWMBXEX503.ctl.intranet> References: <20120821111757.8846.20372.idtracker@ietfa.amsl.com> <50336EBA.1080105@gont.com.ar> <67832B1175062E48926BF3CB27C49B24077F08@xmb-aln-x12.cisco.com>, <1C9F17D1873AFA47A969C4DD98F98A75062E81@xmb-rcd-x10.cisco.com> In-Reply-To: <1C9F17D1873AFA47A969C4DD98F98A75062E81@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.70.40.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: opsec chairs Subject: Re: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-nets-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, 04 Sep 2012 15:36:18 -0000 I too support this draft. I would be ok with bcp or informational. I lean a= bit towards bcp but either category works as long as this reaches expected= audiences. So plus one for support and BCP but wouldn't object to info. (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com ________________________________________ From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] on behalf of Panos Ka= mpanakis (pkampana) [pkampana@cisco.com] Sent: Sunday, September 02, 2012 4:33 PM To: Gunter Van de Velde (gvandeve); Fernando Gont; 'opsec@ietf.org' Cc: opsec chairs Subject: Re: [OPSEC] New Rev of draft-gont-opsec-ipv6-impli= cations-on-ipv4-nets-02.txt 1. Yes. I had provided my thouhgts/feedback for Fernando in previous emails= . 2. Informational (had expressed my reasoning in previous thread) Panos -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of G= unter Van de Velde (gvandeve) Sent: Tuesday, August 21, 2012 7:27 AM To: Fernando Gont; 'opsec@ietf.org' Cc: opsec chairs Subject: Re: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-= nets-02.txt With this note the OPSEC chairs would like to probe for WG adoption. During the cause of events and discussion on the WG mailing list, this docu= ment has been seen as valuable for the WG to adopt as work item. 2 questions need to be addressed: 1. Please find 2 weeks to provide feedback on this draft. Please say yes/no= on WG adoption. 2. Should this be BCP or Informational track G/ -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of F= ernando Gont Sent: 21 August 2012 13:19 To: 'opsec@ietf.org' Cc: opsec chairs Subject: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-nets= -02.txt Folks, FYI, I have posted a new rev of the aforementioned I-D, which is meant to a= ddress the feedback I have received so far. This version should be ready for the formal wg call for adoption-. Thanks! Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt Date: Tue, 21 Aug 2012 04:17:57 -0700 From: internet-drafts@ietf.org To: fernando@gont.com.ar A new version of I-D, draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.tx= t has been successfully submitted by Fernando Gont and posted to the IETF rep= ository. Filename: draft-gont-opsec-ipv6-implications-on-ipv4-nets Revision: 02 Title: Security Implications of IPv6 on IPv4 Networks Creation date: 2012-08-21 WG ID: Individual Submission Number of pages: 18 URL: http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-implications-on-i= pv4-nets-02.txt Status: http://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-implications-on-ipv4-= nets Htmlized: http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets-= 02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-opsec-ipv6-implications-on-ip= v4-nets-02 Abstract: This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. The IETF Secretariat _______________________________________________ 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 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec= From fgont@si6networks.com Tue Sep 4 09:19: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 31B8321F84C9 for ; Tue, 4 Sep 2012 09:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kpmb8C6UyFM5 for ; Tue, 4 Sep 2012 09:19:14 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 87D4421F84C4 for ; Tue, 4 Sep 2012 09:19:14 -0700 (PDT) Received: from [186.134.10.189] (helo=[192.168.123.121]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1T8vqH-0004fb-I9; Tue, 04 Sep 2012 18:19:11 +0200 Message-ID: <504629E1.9080809@si6networks.com> Date: Tue, 04 Sep 2012 13:18:41 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: "'opsec@ietf.org'" X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 04 Sep 2012 16:19:15 -0000 Folks, I was thinking about discussing the following scenario, that I came up with a few days ago: A dual-stacked user (v6 enabled by default) "visits" an IPv4-only network, and establish his VPN with his office (for "mitigating" sniffing attacks, etc.). A local attacker sends forged ICMPv6 RAs, thus triggering IPv6 configuration at the victim nodes. If any of the remote nodes the victim is trying to "visit" is IPv6-enabled, then it's possible/likely that the IPv6 destination address will be used over the IPv4 one. in which case the victim will send his traffic on the local network, as opposed to "through the VPN". Assuming the VPN product does not disable local v6 support, and that the VPN does not provide IPv6 connectivity (*), this attack vector could prove to be an interesting one ("unexpected", to some extent). (*) even then, this attack might still work. Thoughts? 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 dave@juniper.net Tue Sep 4 09:27:25 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 D671B21F8449 for ; Tue, 4 Sep 2012 09:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elfn4nq3GoQo for ; Tue, 4 Sep 2012 09:27:24 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 997B121F8446 for ; Tue, 4 Sep 2012 09:27:20 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKUEYr5aLuwkXOrTzQokGnEnBbQBjqfYl9@postini.com; Tue, 04 Sep 2012 09:27:24 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 4 Sep 2012 09:24:26 -0700 Received: from [172.28.131.163] (172.28.131.163) by p-emfe01-wf.jnpr.net (172.28.145.24) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 4 Sep 2012 12:24:24 -0400 Message-ID: <50462B36.4010506@juniper.net> Date: Tue, 4 Sep 2012 12:24:22 -0400 From: Dave Dugal Organization: Juniper Networks, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <20120821111757.8846.20372.idtracker@ietfa.amsl.com> <50336EBA.1080105@gont.com.ar> <67832B1175062E48926BF3CB27C49B24077F08@xmb-aln-x12.cisco.com>, <1C9F17D1873AFA47A969C4DD98F98A75062E81@xmb-rcd-x10.cisco.com> <68EFACB32CF4464298EA2779B058889D0A1C71E4@PDDCWMBXEX503.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D0A1C71E4@PDDCWMBXEX503.ctl.intranet> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" , opsec chairs , Fernando Gont Subject: Re: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-nets-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, 04 Sep 2012 16:27:25 -0000 Please add my full support for adopting draft-gont-opsec-ipv6-implications-on-ipv4-nets as an OPSEC WG document. While this has enough merit to become a BCP, the current Intended Status of Informational would be my preference. - Dave On 9/4/2012 11:35 AM, Smith, Donald proclaimed ... > I too support this draft. I would be ok with bcp or informational. I lean a bit towards bcp but either category works as long as this reaches expected audiences. > > So plus one for support and BCP but wouldn't object to info. > > > (coffee != sleep) & (!coffee == sleep) > Donald.Smith@centurylink.com > > ________________________________________ > From: opsec-bounces@ietf.org [opsec-bounces@ietf.org] on behalf of Panos Kampanakis (pkampana) [pkampana@cisco.com] > Sent: Sunday, September 02, 2012 4:33 PM > To: Gunter Van de Velde (gvandeve); Fernando Gont; 'opsec@ietf.org' > Cc: opsec chairs > Subject: Re: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt > > 1. Yes. I had provided my thouhgts/feedback for Fernando in previous emails. > 2. Informational (had expressed my reasoning in previous thread) > > Panos > > > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Gunter Van de Velde (gvandeve) > Sent: Tuesday, August 21, 2012 7:27 AM > To: Fernando Gont; 'opsec@ietf.org' > Cc: opsec chairs > Subject: Re: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt > > With this note the OPSEC chairs would like to probe for WG adoption. > > During the cause of events and discussion on the WG mailing list, this document has been seen as valuable for the WG to adopt as work item. > > 2 questions need to be addressed: > > 1. Please find 2 weeks to provide feedback on this draft. Please say yes/no on WG adoption. > 2. Should this be BCP or Informational track > > G/ > > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of Fernando Gont > Sent: 21 August 2012 13:19 > To: 'opsec@ietf.org' > Cc: opsec chairs > Subject: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt > > Folks, > > FYI, I have posted a new rev of the aforementioned I-D, which is meant to address the feedback I have received so far. > > This version should be ready for the formal wg call for adoption-. > > Thanks! > > Best regards, > Fernando > > > > > -------- Original Message -------- > Subject: New Version Notification for > draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt > Date: Tue, 21 Aug 2012 04:17:57 -0700 > From: internet-drafts@ietf.org > To: fernando@gont.com.ar > > > A new version of I-D, draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt > has been successfully submitted by Fernando Gont and posted to the IETF repository. > > Filename: draft-gont-opsec-ipv6-implications-on-ipv4-nets > Revision: 02 > Title: Security Implications of IPv6 on IPv4 Networks > Creation date: 2012-08-21 > WG ID: Individual Submission > Number of pages: 18 > URL: > http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt > Status: > http://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-implications-on-ipv4-nets > Htmlized: > http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-gont-opsec-ipv6-implications-on-ipv4-nets-02 > > Abstract: > This document discusses the security implications of native IPv6 > support and IPv6 transition/co-existence technologies on "IPv4-only" > networks, and describes possible mitigations for the aforementioned > issues. > > > > > > The IETF Secretariat > > > > > _______________________________________________ > 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 > _______________________________________________ > 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 dave@juniper.net Tue Sep 4 09:32: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 0100921F8466 for ; Tue, 4 Sep 2012 09:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwxjxXtjElC2 for ; Tue, 4 Sep 2012 09:32:22 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 6579E21F84F1 for ; Tue, 4 Sep 2012 09:32:22 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUEYtFLsVZakTYIINzhoGJKzXB3p48OL2@postini.com; Tue, 04 Sep 2012 09:32:22 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 4 Sep 2012 09:28:27 -0700 Received: from [172.28.131.163] (172.28.131.163) by p-emfe01-wf.jnpr.net (172.28.145.24) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 4 Sep 2012 12:28:26 -0400 Message-ID: <50462C29.5020500@juniper.net> Date: Tue, 4 Sep 2012 12:28:25 -0400 From: Dave Dugal Organization: Juniper Networks, Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Fernando Gont References: <504629E1.9080809@si6networks.com> In-Reply-To: <504629E1.9080809@si6networks.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 04 Sep 2012 16:32:23 -0000 I agree: interesting (read: dangerously unexpected). This is precisely why one of the SSL VPN gateways I'm intimately familiar with disables IPv6 for the life of the [v4] VPN session. It's a bit inconvenient for me at home, but is the least worst option for the generally unaware user (present company explicitly excluded). - Dave On 9/4/2012 12:18 PM, Fernando Gont proclaimed ... > Folks, > > I was thinking about discussing the following scenario, that I came up > with a few days ago: > > A dual-stacked user (v6 enabled by default) "visits" an IPv4-only > network, and establish his VPN with his office (for "mitigating" > sniffing attacks, etc.). > > A local attacker sends forged ICMPv6 RAs, thus triggering IPv6 > configuration at the victim nodes. > > If any of the remote nodes the victim is trying to "visit" is > IPv6-enabled, then it's possible/likely that the IPv6 destination > address will be used over the IPv4 one. in which case the victim will > send his traffic on the local network, as opposed to "through the VPN". > > Assuming the VPN product does not disable local v6 support, and that the > VPN does not provide IPv6 connectivity (*), this attack vector could > prove to be an interesting one ("unexpected", to some extent). > > (*) even then, this attack might still work. > > Thoughts? > > Thanks! > > Best regards, > From mohacsi@niif.hu Tue Sep 4 09:39:20 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 26D0F21F865D for ; Tue, 4 Sep 2012 09:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfqQTIbLZlpj for ; Tue, 4 Sep 2012 09:39:19 -0700 (PDT) Received: from strudel.ki.iif.hu (strudel.ki.iif.hu [IPv6:2001:738:0:411:20f:1fff:fe6e:ec1e]) by ietfa.amsl.com (Postfix) with ESMTP id 0456821F85A7 for ; Tue, 4 Sep 2012 09:39:18 -0700 (PDT) Received: from cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [193.225.14.182]) by strudel.ki.iif.hu (Postfix) with ESMTP id 0A7F73A7; Tue, 4 Sep 2012 18:39:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at cirkusz.lvs.iif.hu Received: from strudel.ki.iif.hu ([IPv6:::ffff:193.6.222.244]) by cirkusz.lvs.iif.hu (cirkusz.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id OjuwcpwGBBg8; Tue, 4 Sep 2012 18:39:11 +0200 (CEST) Received: by strudel.ki.iif.hu (Postfix, from userid 9002) id 1AA723AE; Tue, 4 Sep 2012 18:39:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by strudel.ki.iif.hu (Postfix) with ESMTP id 0F1753A7; Tue, 4 Sep 2012 18:39:11 +0200 (CEST) Date: Tue, 4 Sep 2012 18:39:11 +0200 (CEST) From: Mohacsi Janos X-X-Sender: mohacsi@strudel.ki.iif.hu To: Fernando Gont In-Reply-To: <504629E1.9080809@si6networks.com> Message-ID: References: <504629E1.9080809@si6networks.com> 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'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 04 Sep 2012 16:39:20 -0000 On Tue, 4 Sep 2012, Fernando Gont wrote: > Folks, > > I was thinking about discussing the following scenario, that I came up > with a few days ago: > > A dual-stacked user (v6 enabled by default) "visits" an IPv4-only > network, and establish his VPN with his office (for "mitigating" > sniffing attacks, etc.). > > A local attacker sends forged ICMPv6 RAs, thus triggering IPv6 > configuration at the victim nodes. > > If any of the remote nodes the victim is trying to "visit" is > IPv6-enabled, then it's possible/likely that the IPv6 destination > address will be used over the IPv4 one. in which case the victim will > send his traffic on the local network, as opposed to "through the VPN". > > Assuming the VPN product does not disable local v6 support, and that the > VPN does not provide IPv6 connectivity (*), this attack vector could > prove to be an interesting one ("unexpected", to some extent). > > (*) even then, this attack might still work. Quite unexpected. VPN service should be also IPv6 capable. > > Thoughts? > > 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 > From gvandeve@cisco.com Tue Sep 4 23:47:49 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 4338821F8513; Tue, 4 Sep 2012 23:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTSDqtDmrnxe; Tue, 4 Sep 2012 23:47:48 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 16DC921F850C; Tue, 4 Sep 2012 23:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=7974; q=dns/txt; s=iport; t=1346827668; x=1348037268; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Xq1WUlcB2XGSx3RQglT2QfXcW+dJLxGOxzh008wvoj8=; b=gIEwuzVe0AIx5WYXAnrgMDWfxf9Td8nMDxw6joH23DZfF/UJ17/l+vMz ofJI3nTLSa1MMfy7HAKGvCbSECdSX06yLcU0RqKc6k9lqV0NGlERKU/08 0B3tFT95ENAkTFiT3os2WCZBx5HX3IE9QZE0Z08NWg5rVttuvneE9Z1UH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAJX0RlCtJV2d/2dsb2JhbABFgkqnM4hTAYhTgQeCIQEBBBIBGkwQAgEIFA4kMiUBAQQBDQ0ah2sLmmOgK4sRhiJgA5ZtjR+BZ4Jj X-IronPort-AV: E=Sophos;i="4.80,372,1344211200"; d="scan'208,217";a="118367271" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 05 Sep 2012 06:47:47 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q856llPF009808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Sep 2012 06:47:47 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.191]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.001; Wed, 5 Sep 2012 01:47:47 -0500 From: "Gunter Van de Velde (gvandeve)" To: "draft-vyncke-opsec-v6@tools.ietf.org" , "opsec@ietf.org" Thread-Topic: WG adoption of draft-vyncke-opsec-v6 Thread-Index: Ac2LMAEU8PlJ5TgLS6yA+ViKRvG0JgAAjyHg Date: Wed, 5 Sep 2012 06:47:46 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240337A508@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B240337A4E5@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B240337A4E5@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.108.76] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19164.001 x-tm-as-result: No--30.392700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240337A508xmbalnx12ciscoc_" MIME-Version: 1.0 Cc: "V6ops Chairs \(v6ops-chairs@tools.ietf.org\)" , "opsec-chairs@ietf.org" Subject: Re: [OPSEC] WG adoption of draft-vyncke-opsec-v6 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: Wed, 05 Sep 2012 06:47:49 -0000 --_000_67832B1175062E48926BF3CB27C49B240337A508xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear authors, Please submit this draft as WG item. I added the v6ops chairs as liaison information as it is very close to IPv6= Operations. G/ Date: 20 August 2012 Dear WG, During the latest OPSEC meeting the draft draft-vyncke-opsec-v6-01 was pres= ented. The document received positive feedback from the people that read the docum= ent. To give more people the chance to read the document before asking on the WG= list for adoption it was agreed to wait about three weeks to give that cha= nce. Current document: http://datatracker.ietf.org/doc/draft-vyncke-opsec-v6/ Kindly provide feedback on this document during the next two weeks for adop= tion of this work as WG document. Unless mayor issues with the document are= identified in that period, this document will be accepted as WG document. Kind Regards, G/ --_000_67832B1175062E48926BF3CB27C49B240337A508xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Dear authors,

 

Please submit this draft as WG item.

I added the v6ops chairs as liaison information as i= t is very close to IPv6 Operations.

 

G/

 

 

Date: 20 August 2012

Dear WG,

 

During the latest OPSEC meetin= g the draft draft-vyncke-opsec-v6-01 was presented.

The document received positive= feedback from the people that read the document.

 

To give more people the chance= to read the document before asking on the WG list for adoption it was agre= ed to wait about three weeks to give that chance.

 

Current document: http://datatracker.ietf.org/doc/draft-vynck= e-opsec-v6/

 

Kindly provide feedback on thi= s document during the next two weeks for adoption of this work as WG docume= nt. Unless mayor issues with the document are identified in that period, th= is document will be accepted as WG document.

 

Kind Regards,

G/

 

--_000_67832B1175062E48926BF3CB27C49B240337A508xmbalnx12ciscoc_-- From aservin@lacnic.net Wed Sep 5 00:41:46 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 1DDE121F84C8 for ; Wed, 5 Sep 2012 00:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdXeVfIJGf-j for ; Wed, 5 Sep 2012 00:41:45 -0700 (PDT) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 72EF521F852E for ; Wed, 5 Sep 2012 00:41:45 -0700 (PDT) Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.90]) by mail.lacnic.net.uy (Postfix) with ESMTP id 4C23B308424; Wed, 5 Sep 2012 04:41:34 -0300 (UYT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Arturo Servin In-Reply-To: <67832B1175062E48926BF3CB27C49B24077F08@xmb-aln-x12.cisco.com> Date: Wed, 5 Sep 2012 08:41:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120821111757.8846.20372.idtracker@ietfa.amsl.com> <50336EBA.1080105@gont.com.ar> <67832B1175062E48926BF3CB27C49B24077F08@xmb-aln-x12.cisco.com> To: Gunter Van de Velde (gvandeve) X-Mailer: Apple Mail (2.1278) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: "'opsec@ietf.org'" , opsec chairs , Fernando Gont Subject: Re: [OPSEC] New Rev of draft-gont-opsec-ipv6-implications-on-ipv4-nets-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: Wed, 05 Sep 2012 07:41:46 -0000 I have read and I support it for WG adoption. Regards, as On 21 Aug 2012, at 12:27, Gunter Van de Velde (gvandeve) wrote: > With this note the OPSEC chairs would like to probe for WG adoption. >=20 > During the cause of events and discussion on the WG mailing list, this = document has been seen as valuable for the WG to adopt as work item. >=20 > 2 questions need to be addressed: >=20 > 1. Please find 2 weeks to provide feedback on this draft. Please say = yes/no on WG adoption.=20 > 2. Should this be BCP or Informational track >=20 > G/ >=20 > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf = Of Fernando Gont > Sent: 21 August 2012 13:19 > To: 'opsec@ietf.org' > Cc: opsec chairs > Subject: [OPSEC] New Rev of = draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt >=20 > Folks, >=20 > FYI, I have posted a new rev of the aforementioned I-D, which is meant = to address the feedback I have received so far. >=20 > This version should be ready for the formal wg call for adoption-. >=20 > Thanks! >=20 > Best regards, > Fernando >=20 >=20 >=20 >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt > Date: Tue, 21 Aug 2012 04:17:57 -0700 > From: internet-drafts@ietf.org > To: fernando@gont.com.ar >=20 >=20 > A new version of I-D, = draft-gont-opsec-ipv6-implications-on-ipv4-nets-02.txt > has been successfully submitted by Fernando Gont and posted to the = IETF repository. >=20 > Filename: draft-gont-opsec-ipv6-implications-on-ipv4-nets > Revision: 02 > Title: Security Implications of IPv6 on IPv4 Networks > Creation date: 2012-08-21 > WG ID: Individual Submission > Number of pages: 18 > URL: > = http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-implications-on-= ipv4-nets-02.txt > Status: > = http://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-implications-on-ipv4= -nets > Htmlized: > = http://tools.ietf.org/html/draft-gont-opsec-ipv6-implications-on-ipv4-nets= -02 > Diff: > = http://www.ietf.org/rfcdiff?url2=3Ddraft-gont-opsec-ipv6-implications-on-i= pv4-nets-02 >=20 > Abstract: > This document discusses the security implications of native IPv6 > support and IPv6 transition/co-existence technologies on "IPv4-only" > networks, and describes possible mitigations for the aforementioned > issues. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > _______________________________________________ > 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 sorr@cisco.com Wed Sep 5 16:19: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 D86B121F86C8 for ; Wed, 5 Sep 2012 16:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0Hw43udqPjV for ; Wed, 5 Sep 2012 16:19:13 -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 8C02C21F86D5 for ; Wed, 5 Sep 2012 16:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4977; q=dns/txt; s=iport; t=1346887153; x=1348096753; h=from:to:cc:subject:date:message-id:mime-version; bh=rlAQKqAQJGgQ1e16Esi1Oe1kSux2s9aJuLYcWjvRO+M=; b=iJVnhQ0zYO7+8wRQUdb+y7/5uZXdfcp2sqeNhNNHcaSwXhOgUuBq72Ik S1EcBjSMqUKfI/f99wKeifflJrAbFPjohq/k+YjMtfWAiAtj4/wJvBjPx eEJMzw/G+zCtA2lmzHWzcCwgABPZRNxI7kdnSRVm08zqytd/buZKe18fs k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKrcR1CtJXG+/2dsb2JhbAA7CoJKuFuBB4IiAQQSARpMEgEaEFYXDwEEDg0ah2uaVqAciyGFVWADpAyBZ4Jj X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208,217";a="118709335" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 05 Sep 2012 23:19:13 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q85NJDN8010263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Sep 2012 23:19:13 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.118]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Wed, 5 Sep 2012 18:19:12 -0500 From: "Stephen Orr (sorr)" To: "opsec@ietf.org" Thread-Topic: request for review of draft-orr-wireless-lan-architectures-00 Thread-Index: Ac2LvNQ8bKOr/upEQb+8jRRGELNEgQ== Date: Wed, 5 Sep 2012 23:19:11 +0000 Message-ID: <06A07C6179EDEE48895CE9661FD0E41D0F562EF5@xmb-rcd-x11.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.148.212] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.001 x-tm-as-result: No--35.665300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_06A07C6179EDEE48895CE9661FD0E41D0F562EF5xmbrcdx11ciscoc_" MIME-Version: 1.0 Cc: "Anthony Grieco \(agrieco\)" Subject: [OPSEC] request for review of draft-orr-wireless-lan-architectures-00 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: Wed, 05 Sep 2012 23:24:41 -0000 --_000_06A07C6179EDEE48895CE9661FD0E41D0F562EF5xmbrcdx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Can I request that some members of the opsec WG review a draft that I recen= tly submitted: draft-orr-wireless-lan-architectures-00 "Cryptographic Secu= rity Characteristics of 802.11 Wireless LAN Access Systems." The intent of the informational draft is to identify all of the places that= cryptography is used in Wireless Local Area Network (WLAN) architectures, = to simplify the task of selecting the protocols, algorithms, and key sizes = needed to achieve a consistent security level across the entire architectu= re. As Wireless LAN Access systems are deployed today there is no clearly defin= ed end-to-end security consistency required which could result in the overa= ll cryptographic strength of the WLAN System being brought down to the lowe= st cryptographic strength of one of the components. With this draft we are = hoping to lay the foundation for other's to construct profiles that should = specify the exact end-to-end cryptographic characteristics required to prov= ide consistency. Thanks in advance. Regards Stephen Orr --_000_06A07C6179EDEE48895CE9661FD0E41D0F562EF5xmbrcdx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Can I request that some members of the opsec WG revi= ew a draft that I recently submitted:  draft-orr-wireless-lan-architec= tures-00 “Cryptographic Security Characteristics of 802.11 Wireless L= AN Access Systems.”

 

The intent of the info= rmational draft is to identify all of the places that cryptography is used = in Wireless Local Area Network (WLAN) architectures, to simplify the task o= f selecting the protocols, algorithms, and key sizes needed to  achieve a consistent security level across t= he entire architecture.

 

As Wireless LAN Access= systems are deployed today there is no clearly defined end-to-end security= consistency required which could result in the overall cryptographic stren= gth of the WLAN System being brought down to the lowest cryptographic strength of one of the components. With t= his draft we are hoping to lay the foundation for other’s to construc= t profiles that should specify the exact end-to-end cryptographic character= istics required to provide consistency.

 

Thanks in advance.

 

Regards

 

Stephen Orr=

--_000_06A07C6179EDEE48895CE9661FD0E41D0F562EF5xmbrcdx11ciscoc_-- From gvandeve@cisco.com Wed Sep 5 23:11:29 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 E061C21F851B for ; Wed, 5 Sep 2012 23:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NaRvqNG2Nec for ; Wed, 5 Sep 2012 23:11:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8769E21F84F5 for ; Wed, 5 Sep 2012 23:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19046; q=dns/txt; s=iport; t=1346911887; x=1348121487; h=from:to:subject:date:message-id:mime-version; bh=pyiE3gjE+7dpvnYlciE9tsrrSWeBnF8wErki7QBEnZs=; b=QHywW88pzclCDPtYY5amVtq1/saJzx3xWG7gHRODCvYIC1ZK1Q+8j5X+ wv3zpAK5OMueD9r/OW/k3lyptH9uzuhjiSu7iobHMUVUaUN+90GC22XQo H8qZ6PTflJQYtstxXML1rNOcpHrcvUSiyFLuWrtoUPFgioi0qjvj+jXxK M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA8+SFCtJXG8/2dsb2JhbABFgkq4WoEHgiABAQEEEgEaXgEdDQJUJgEEGwEZh2sLmSWBKKASixGFZWADpAyBZ4JjgVgE X-IronPort-AV: E=Sophos;i="4.80,377,1344211200"; d="scan'208,217";a="118763750" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 06 Sep 2012 06:11:21 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q866BLe2010210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 6 Sep 2012 06:11:21 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.191]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Thu, 6 Sep 2012 01:11:20 -0500 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: Importat dates - IETF85 Thread-Index: Ac2L9l4S/Ol962C/ScuT39WebfjD1A== Date: Thu, 6 Sep 2012 06:11:19 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240813445D@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.108.76] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19166.004 x-tm-as-result: No--47.420700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240813445Dxmbalnx12ciscoc_" MIME-Version: 1.0 Subject: [OPSEC] Importat dates - IETF85 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, 06 Sep 2012 06:11:29 -0000 --_000_67832B1175062E48926BF3CB27C49B240813445Dxmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF85 IETF 85: November 4-9, 2012, Atlanta, GA, USA Download .ICS = file of important dates for IETF 85 Subscribe to important dates calendar for IETF 85: http://www.ietf.org/meet= ing/85/ietf-85-important-dates.ics * 2012-08-0613 (Week of): IETF Online Registration opens. *UPDATED* * 2012-08-0613 (Monday Week of): Working Group and BOF scheduling begin= s. To request a Working Group session, use the IETF Meeting Session Request= Tool. *U= PDATED* * 2012-09-10 (Monday): Cutoff date for requests to schedule Working Gro= up meetings at UTC 24:00. To request a Working Group session, use the IETF = Meeting Session Request Tool. * 2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area Di= rectors at UTC 24:00. To request a BOF, please see instructions on Requesti= ng a BOF. * 2012-09-27 (Thursday): Cutoff date for Area Directors to approve BOFs= at UTC 24:00. * 2012-10-04 (Thursday): Preliminary agenda published for comment. * 2012-10-08 (Monday): Cutoff date for requests to reschedule Working G= roup and BOF meetings UTC 24:00. * 2012-10-08 (Monday): Working Group Chair approval for initial documen= t (Version -00) submissions appreciated by UTC 24:00. * 2012-10-12 (Friday): Final agenda to be published. * 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00= ) submission by UTC 24:00, upload using IETF ID Submission Tool. * 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 2= 4:00, upload using IETF ID Submission Tool. * 2012-10-24 (Wednesday): Draft Working Group agendas due by UTC 24:00,= upload using IETF Meeting Materials Management Tool. * 2012-10-26 (Friday): Early Bird registration and payment cut-off at U= TC 24:00. * 2012-10-29 (Monday): Revised Working Group agendas due by UTC 24:00, = upload using IETF Meeting Materials Management Tool. * 2012-10-29 (Monday): Registration cancellation cut-off at UTC 24:00. * 2012-11-02 (Friday): Final Pre-Registration and Pre-Payment cut-off a= t 17:00 local meeting time. * 2012-11-04 - 2012-11-09: 85th IETF Meeting in Atlanta, GA, USA. * 2012-12-07 (Friday): Proceedings submission cutoff date by UTC 24:00,= upload using IETF Meeting Materials Management Tool. * 2012-12-26 (Wednesday): Proceedings submission corrections cutoff dat= e by UTC 24:00, upload using IETF Meeting Materials Management Tool. --_000_67832B1175062E48926BF3CB27C49B240813445Dxmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF85

 

IETF 85: November 4-= 9, 2012, Atlanta, GA, USA

Download .ICS file of important dates for IETF 85
Subscribe to important dates calendar for IETF 85: http://www.ietf.org/meet= ing/85/ietf-85-important-dates.ics

  • 2012-08-0613 (Week of): IETF Online Registration opens. *UPDATED*
  • 2012-08-0613 (Monday Week of): Working Group and BOF scheduling begins. To request a Wor= king Group session, use the IETF Meeting Session Request Tool. *UPDATED*
  • 2012-09-10 (Monday): Cutoff= date for requests to schedule Working Group meetings at UTC 24:00. To requ= est a Working Group session, use the IETF Meeting Session Request Tool.
  • 2012-09-24 (Monday): Cutoff= date for BOF proposal requests to Area Directors at UTC 24:00. To request = a BOF, please see instructions on Requesting a BOF.
  • 2012-09-27 (Thursday): Cuto= ff date for Area Directors to approve BOFs at UTC 24:00.<= /li>
  • 2012-10-04 (Thursday): Prel= iminary agenda published for comment.
  • 2012-10-08 (Monday): Cutoff= date for requests to reschedule Working Group and BOF meetings UTC 24:00.<= o:p>
  • 2012-10-08 (Monday): Workin= g Group Chair approval for initial document (Version -00) submissions appre= ciated by UTC 24:00.
  • 2012-10-12 (Friday): Final = agenda to be published.
  • 2012-10-15 (Monday): Intern= et Draft Cut-off for initial document (-00) submission by UTC 24:00, upload using IETF ID Submission = Tool.
  • 2012-10-22 (Monday): Intern= et Draft final submission cut-off by UTC 24:00, upload using IETF ID Submission Tool.
  • 2012-10-24 (Wednesday): Dra= ft Working Group agendas due by UTC 24:00, upload using IETF= Meeting Materials Management Tool.
  • 2012-10-26 (Friday): Early = Bird registration and payment cut-off at UTC 24:00.
    • <= li class=3D"MsoNormal" style=3D"color:black;mso-margin-top-alt:auto;mso-mar= gin-bottom-alt:auto;mso-list:l0 level1 lfo1"> 2012-10-29 (Monday): Revise= d Working Group agendas due by UTC 24:00, upload using IETF= Meeting Materials Management Tool.
  • 2012-10-29 (Monday): Regist= ration cancellation cut-off at UTC 24:00.
  • 2012-11-02 (Friday): Final = Pre-Registration and Pre-Payment cut-off at 17:00 local meeting time.
  • 2012-11-04 - 2012-11-09: 85th IETF Meeting in Atlanta, = GA, USA.
  • 2012-12-07 (Friday): Procee= dings submission cutoff date by UTC 24:00, upload using IETF= Meeting Materials Management Tool.
  • 2012-12-26 (Wednesday): Pro= ceedings submission corrections cutoff date by UTC 24:00, upload using IETF= Meeting Materials Management Tool.

 

--_000_67832B1175062E48926BF3CB27C49B240813445Dxmbalnx12ciscoc_-- From kkumar@google.com Thu Sep 6 06:55:41 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 B10B521F8673 for ; Thu, 6 Sep 2012 06:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wlf3mRlU0++P for ; Thu, 6 Sep 2012 06:55:41 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE5BB21F863F for ; Thu, 6 Sep 2012 06:55:40 -0700 (PDT) Received: by lbky2 with SMTP id y2so1320018lbk.31 for ; Thu, 06 Sep 2012 06:55:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=aT6EcXL6V8GD5QjDwKi3bQOKkf8/h/bBQNIZIyacvJY=; b=nsuo3ymFulFgiDRx89JSofYL7hhKjbyqd0VewZisIkj21I7mtkzRRFFawsT/ItLyDk KBMUbsP8wCj2i6DHRwbgkKC466DuH12AgLz8MY+CU0DbuHk/HYme/S+asJr840oj0ycb phz+vrGZYReLeA84XoI1s/ottFsGxeZ/35RyouYhxWRf8iFO+scYWdmGbud+ggNKat3c 7GtwAiepN+y91sKAdDA282JlIal2IWhc6YD8OAA8kY+d7wfmVP4T9LlKsGAcK5nMOYUG G/AkTo99TVvh6yUCrtWrTc8Du3QHXND1BJTG0KAvEhC9HIrZ/KU/81VYiXU0FPsfpUwQ gtMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=aT6EcXL6V8GD5QjDwKi3bQOKkf8/h/bBQNIZIyacvJY=; b=LBbbpmUKet2BtW+5Vt7VUUCPJRJyQphW2W3x/msLxSQctfCasPAIlLP9MAPixBPcc+ d1lfmBOt9GEUodsO3UicXHzJ4Qz1/aRdxQhb1y2NaHQfKFAzCQ/xtg+W/Gzz5h/XBNiR ENwRPqMUYhgjjH3gtjKzDrl54zicTRahccNCDwtivJfc3QZrd1nVQ2jZCabd9JA3AQbl MwL8iwIx5BoLWKstfGN9BmKnpppg6qXoN8AhnIqJC54yZOxnEoO6XpfhDdNRmzIApHyl B7xhYYb8/5hkj3P3VVvntY+OayF/Gnuir4nEJ40P0DARzHOKv0i7/X9CovNid1pFhCs6 3tqQ== Received: by 10.112.29.104 with SMTP id j8mr883180lbh.127.1346939739643; Thu, 06 Sep 2012 06:55:39 -0700 (PDT) Received: by 10.112.29.104 with SMTP id j8mr883171lbh.127.1346939739337; Thu, 06 Sep 2012 06:55:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.66.42 with HTTP; Thu, 6 Sep 2012 06:55:19 -0700 (PDT) In-Reply-To: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> References: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> From: KK Date: Thu, 6 Sep 2012 06:55:19 -0700 Message-ID: To: opsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQl3785X5WOg1EULVKERHcJ0w0a8RdwqJa4GYI2EdSrtRtDIn3YvJnib/Ju+OU5ygjJ4zk1Fxm4WZnzbFiFhfEdLuIVvex3tD9ggdeFB7/yrWBj/sj/iANpXiHXHBVe7Va1KjZBHJx8huXdII9lUE9vvG+kQaUJatevZEz37nvY761hlCmFMTFDQHMB0sEDFHIFQXjwB Subject: [OPSEC] Fwd: Help the NomCom: Nominations and Feedback 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, 06 Sep 2012 13:55:41 -0000 Hey Folks, Please help the NomCom with your nominations and feedback. Thanks, KK ---------- Forwarded message ---------- From: NomCom Chair Date: Wed, Sep 5, 2012 at 5:21 PM Subject: Help the NomCom: Nominations and Feedback To: Working Group Chairs The IETF Nominations Committee (NomCom) is currently seeking nominations for individuals to serve on the IESG, IAB, and IAOC. Additionally, this is an announcement that the NomCom is seeking feedback on individuals who have accepted nominations for IETF leadership positions. It is very important to the NomCom process that we get input from a broad spectrum of the community. Therefore, in case members of your working group do not read the IETF announcement and discussion lists, the NomCom would appreciate your help in disseminating the following information. The NomCom website contains information about this year's NomCom including the positions we are seeking to fill, and the qualifications required for these positions: https://www.ietf.org/group/nomcom/2012/ The NomCom is accepting nominations until September 24. Nominations for any position can be made using the following web tool: https://www.ietf.org/group/nomcom/2012/nominate Feedback about individuals who the NomCom is considering can be providing using the following web tool: https://www.ietf.org/group/nomcom/2012/input The feedback tool provides a list of individuals who have agreed to be considered for each position. We will be updating this list in the coming weeks as more individuals accept nominations. Feedback provided to the NomCom is kept strictly confidential! Note that use of the NomCom web tools require an ietf.org (i.e., datatracker) account. You can create an ietf.org account by visiting the following URL: https://datatracker.ietf.org/accounts/create/ As an alternative to using the web tools, you can send email to the NomCom at nomcom12@ietf.org to make a nomination or provide input to the committee. Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org From fgont@si6networks.com Mon Sep 10 08:06:39 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 9D56321F8700 for ; Mon, 10 Sep 2012 08:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeI6FaDDs8NB for ; Mon, 10 Sep 2012 08:06:39 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1B04321F86FF for ; Mon, 10 Sep 2012 08:06:39 -0700 (PDT) Received: from [200.61.210.165] (helo=[172.17.59.172]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TB5ZK-0003yx-Cl; Mon, 10 Sep 2012 17:06:34 +0200 Message-ID: <504DFC3C.9060804@si6networks.com> Date: Mon, 10 Sep 2012 11:42:04 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Mohacsi Janos References: <504629E1.9080809@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 10 Sep 2012 15:06:39 -0000 Hi, Mohacsi, On 09/04/2012 01:39 PM, Mohacsi Janos wrote: >> (*) even then, this attack might still work. > > Quite unexpected. VPN service should be also IPv6 capable. Problem is, the remote network with which the nomadic node is establishing a VPN may simply not support IPv6. That aside, I wonder what's the mechanism that the VPN software employs to cause all v6 traffic to be sent on the VPN -- if it's just removing the existing IPv6 default route, or leveraging IPv6 route priorities, that could easily be circumvented by means of forged RAs. 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 ayourtch@cisco.com Mon Sep 10 08:34: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 D3D8721F8710 for ; Mon, 10 Sep 2012 08:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bh-PV4GexX24 for ; Mon, 10 Sep 2012 08:34:37 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 82C6C21F870F for ; Mon, 10 Sep 2012 08:34:37 -0700 (PDT) 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 q8AFYa9F005067 for ; Mon, 10 Sep 2012 17:34:36 +0200 (CEST) Received: from ams-ayourtch-87110.cisco.com (ams-ayourtch-87110.cisco.com [10.55.144.251]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8AFYYne011731; Mon, 10 Sep 2012 17:34:34 +0200 (CEST) Date: Mon, 10 Sep 2012 17:34:33 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx To: Fernando Gont In-Reply-To: <504629E1.9080809@si6networks.com> Message-ID: References: <504629E1.9080809@si6networks.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 10 Sep 2012 15:34:38 -0000 On Tue, 4 Sep 2012, Fernando Gont wrote: > Folks, > > I was thinking about discussing the following scenario, that I came up > with a few days ago: > > A dual-stacked user (v6 enabled by default) "visits" an IPv4-only > network, and establish his VPN with his office (for "mitigating" > sniffing attacks, etc.). > > A local attacker sends forged ICMPv6 RAs, thus triggering IPv6 > configuration at the victim nodes. > > If any of the remote nodes the victim is trying to "visit" is > IPv6-enabled, then it's possible/likely that the IPv6 destination > address will be used over the IPv4 one. in which case the victim will > send his traffic on the local network, as opposed to "through the VPN". > > Assuming the VPN product does not disable local v6 support, and that the > VPN does not provide IPv6 connectivity (*), this attack vector could > prove to be an interesting one ("unexpected", to some extent). > > (*) even then, this attack might still work. > > Thoughts? Would the working scenario of this attack not be the more specific case of the classic "IPv4-only access network; dualstack target; IPv6 MITM" case ? There are two differences that I see though: 1) The difference between the trust level for IPv4 "legit" leg and IPv6 "rogue" leg is even further apart than in the simple case. This is kind of interesting, but not terribly. 2) The IPv4 leg over VPN noticeably increases the latency. Now, this could be a dealbreaker, since it becomes way easier to race - especially given that for this scenario we'd be talking primarily wireless attackers, with a very tight delay budget. --a > > 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 > > From fgont@si6networks.com Mon Sep 10 14:09:28 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 6EBC811E80E6 for ; Mon, 10 Sep 2012 14:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQ+s00rUEHgd for ; Mon, 10 Sep 2012 14:09:28 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 7B07021F8737 for ; Mon, 10 Sep 2012 14:09:27 -0700 (PDT) Received: from [190.245.182.195] (helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TBBEQ-0005bR-Ti; Mon, 10 Sep 2012 23:09:23 +0200 Message-ID: <504E56FB.3020401@si6networks.com> Date: Mon, 10 Sep 2012 18:09:15 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Andrew Yourtchenko References: <504629E1.9080809@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 10 Sep 2012 21:09:28 -0000 On 09/10/2012 12:34 PM, Andrew Yourtchenko wrote: >> If any of the remote nodes the victim is trying to "visit" is >> IPv6-enabled, then it's possible/likely that the IPv6 destination >> address will be used over the IPv4 one. in which case the victim will >> send his traffic on the local network, as opposed to "through the VPN". >> >> Assuming the VPN product does not disable local v6 support, and that the >> VPN does not provide IPv6 connectivity (*), this attack vector could >> prove to be an interesting one ("unexpected", to some extent). >> >> (*) even then, this attack might still work. >> >> Thoughts? > > Would the working scenario of this attack not be the more specific case > of the classic "IPv4-only access network; dualstack target; IPv6 MITM" case ? Yes. Although the security assumptions in each of these two cases are totally different -- in the VPN case, your "secured" traffic goes, all out of the sudden, unsecured. > 2) The IPv4 leg over VPN noticeably increases the latency. Now, this > could be a dealbreaker, since it becomes way easier to race - especially > given that for this scenario we'd be talking primarily wireless > attackers, with a very tight delay budget. Are you thinking abut happyeyeballs? Cheers, -- 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 Mon Sep 10 15:18: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 E0C4621F864D for ; Mon, 10 Sep 2012 15:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-pWEBz57119 for ; Mon, 10 Sep 2012 15:18:03 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 94B2121F8645 for ; Mon, 10 Sep 2012 15:18:02 -0700 (PDT) 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 q8AMI1T2011878 for ; Tue, 11 Sep 2012 00:18:01 +0200 (CEST) Received: from ams-ayourtch-87110.cisco.com (ams-ayourtch-87110.cisco.com [10.55.144.251]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8AMHwm3001101; Tue, 11 Sep 2012 00:17:58 +0200 (CEST) Date: Tue, 11 Sep 2012 00:17:58 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx To: Fernando Gont In-Reply-To: <504E56FB.3020401@si6networks.com> Message-ID: References: <504629E1.9080809@si6networks.com> <504E56FB.3020401@si6networks.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 10 Sep 2012 22:18:05 -0000 On Mon, 10 Sep 2012, Fernando Gont wrote: > On 09/10/2012 12:34 PM, Andrew Yourtchenko wrote: >>> If any of the remote nodes the victim is trying to "visit" is >>> IPv6-enabled, then it's possible/likely that the IPv6 destination >>> address will be used over the IPv4 one. in which case the victim will >>> send his traffic on the local network, as opposed to "through the VPN". >>> >>> Assuming the VPN product does not disable local v6 support, and that the >>> VPN does not provide IPv6 connectivity (*), this attack vector could >>> prove to be an interesting one ("unexpected", to some extent). >>> >>> (*) even then, this attack might still work. >>> >>> Thoughts? >> >> Would the working scenario of this attack not be the more specific case >> of the classic "IPv4-only access network; dualstack target; IPv6 MITM" case ? > > Yes. Although the security assumptions in each of these two cases are > totally different -- in the VPN case, your "secured" traffic goes, all > out of the sudden, unsecured. Exactly. Though I viewed this as just the different level of trust. Both in the VPN and non-VPN case I usually can somewhat reasonably assume that there is noone listening to my traffic right now, and in the VPN case this assumption is somewhat stronger (Cracking a 4096 bit RSA is a bit more work than reading plaintext but possible: http://xkcd.com/538/; Can be conveniently applied to the CA of choice). > >> 2) The IPv4 leg over VPN noticeably increases the latency. Now, this >> could be a dealbreaker, since it becomes way easier to race - especially >> given that for this scenario we'd be talking primarily wireless >> attackers, with a very tight delay budget. > > Are you thinking abut happyeyeballs? > yeah. while the "classic" rfc3484 behavior is a disaster outright, the HE, with its much shortened fallback to IPv4, should be helping. But in some implementations this advantage might be less than in the others. Maybe interesting testing this stuff. --a > Cheers, > -- > 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 Thu Sep 13 08:28:01 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 3E81E21F85A7 for ; Thu, 13 Sep 2012 08:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjfKc9aJKTpe for ; Thu, 13 Sep 2012 08:28:00 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 307DF21F85A3 for ; Thu, 13 Sep 2012 08:28:00 -0700 (PDT) Received: from [186.134.45.26] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TCBKb-00029l-Ig; Thu, 13 Sep 2012 17:27:53 +0200 Message-ID: <5051FB6F.2070204@si6networks.com> Date: Thu, 13 Sep 2012 12:27:43 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Andrew Yourtchenko References: <504629E1.9080809@si6networks.com> <504E56FB.3020401@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 13 Sep 2012 15:28:01 -0000 Hi, Andrew, On 09/10/2012 07:17 PM, Andrew Yourtchenko wrote: >>> Would the working scenario of this attack not be the more specific case >>> of the classic "IPv4-only access network; dualstack target; IPv6 >>> MITM" case ? >> >> Yes. Although the security assumptions in each of these two cases are >> totally different -- in the VPN case, your "secured" traffic goes, all >> out of the sudden, unsecured. > > Exactly. Though I viewed this as just the different level of trust. Both > in the VPN and non-VPN case I usually can somewhat reasonably assume > that there is noone listening to my traffic right now, and in the VPN > case this assumption is somewhat stronger (Cracking a 4096 bit RSA is a > bit more work than reading plaintext but possible: http://xkcd.com/538/; > Can be conveniently applied to the CA of choice). Agreed. >>> 2) The IPv4 leg over VPN noticeably increases the latency. Now, this >>> could be a dealbreaker, since it becomes way easier to race - especially >>> given that for this scenario we'd be talking primarily wireless >>> attackers, with a very tight delay budget. >> >> Are you thinking abut happyeyeballs? > > yeah. while the "classic" rfc3484 behavior is a disaster outright, the > HE, with its much shortened fallback to IPv4, should be helping. But in > some implementations this advantage might be less than in the others. > Maybe interesting testing this stuff. Well, one would expect that in this case, the attacker would always win if HE is in place, right? P.S.: I'm all for the testing -- will do it for openvpn. Many other have already reported vulnerable implementations on the corresponding thread at the ipv6hackers mailing-list (). 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 ayourtch@cisco.com Thu Sep 13 09:24:06 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 1A8DB21F859F for ; Thu, 13 Sep 2012 09:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXVgaV68Xvs1 for ; Thu, 13 Sep 2012 09:24:05 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 8C35A21F859E for ; Thu, 13 Sep 2012 09:24:00 -0700 (PDT) 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 q8DGNuKl003377 for ; Thu, 13 Sep 2012 18:23:56 +0200 (CEST) Received: from ams-ayourtch-87110.cisco.com (ams-ayourtch-87110.cisco.com [10.55.144.251]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q8DGNtrn003135; Thu, 13 Sep 2012 18:23:55 +0200 (CEST) Date: Thu, 13 Sep 2012 18:23:55 +0200 (CEST) From: Andrew Yourtchenko X-X-Sender: ayourtch@ayourtch-lnx To: Fernando Gont In-Reply-To: <5051FB6F.2070204@si6networks.com> Message-ID: References: <504629E1.9080809@si6networks.com> <504E56FB.3020401@si6networks.com> <5051FB6F.2070204@si6networks.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 13 Sep 2012 16:24:06 -0000 Hi Fernando, On Thu, 13 Sep 2012, Fernando Gont wrote: > Hi, Andrew, > > On 09/10/2012 07:17 PM, Andrew Yourtchenko wrote: >>>> Would the working scenario of this attack not be the more specific case >>>> of the classic "IPv4-only access network; dualstack target; IPv6 >>>> MITM" case ? >>> >>> Yes. Although the security assumptions in each of these two cases are >>> totally different -- in the VPN case, your "secured" traffic goes, all >>> out of the sudden, unsecured. >> >> Exactly. Though I viewed this as just the different level of trust. Both >> in the VPN and non-VPN case I usually can somewhat reasonably assume >> that there is noone listening to my traffic right now, and in the VPN >> case this assumption is somewhat stronger (Cracking a 4096 bit RSA is a >> bit more work than reading plaintext but possible: http://xkcd.com/538/; >> Can be conveniently applied to the CA of choice). > > Agreed. > > >>>> 2) The IPv4 leg over VPN noticeably increases the latency. Now, this >>>> could be a dealbreaker, since it becomes way easier to race - especially >>>> given that for this scenario we'd be talking primarily wireless >>>> attackers, with a very tight delay budget. >>> >>> Are you thinking abut happyeyeballs? >> >> yeah. while the "classic" rfc3484 behavior is a disaster outright, the >> HE, with its much shortened fallback to IPv4, should be helping. But in >> some implementations this advantage might be less than in the others. >> Maybe interesting testing this stuff. > > Well, one would expect that in this case, the attacker would always win > if HE is in place, right? Actually, HE makes attacker's life harder than the "classic" TCP timeout-based - because in the latter case the IPv6 will take precedence, and the attacker has all the time. In the HE case, the window is way shorter. --a > > P.S.: I'm all for the testing -- will do it for openvpn. Many other have > already reported vulnerable implementations on the corresponding thread > at the ipv6hackers mailing-list > (). > ;-) cool, thanks! > 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 gert@space.net Thu Sep 13 11:15: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 7A2C721F8600 for ; Thu, 13 Sep 2012 11:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e965rO5CN+i6 for ; Thu, 13 Sep 2012 11:15:35 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id CDE5D21F85FC for ; Thu, 13 Sep 2012 11:15:33 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 2C6D1F8ECB for ; Thu, 13 Sep 2012 20:15:32 +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 DA222F8EC0 for ; Thu, 13 Sep 2012 20:15:31 +0200 (CEST) Received: (qmail 32235 invoked by uid 1007); 13 Sep 2012 20:15:31 +0200 Date: Thu, 13 Sep 2012 20:15:31 +0200 From: Gert Doering To: Fernando Gont Message-ID: <20120913181531.GO13776@Space.Net> References: <504629E1.9080809@si6networks.com> <504E56FB.3020401@si6networks.com> <5051FB6F.2070204@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5051FB6F.2070204@si6networks.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 13 Sep 2012 18:15:35 -0000 Hi, On Thu, Sep 13, 2012 at 12:27:43PM -0300, Fernando Gont wrote: > P.S.: I'm all for the testing -- will do it for openvpn. OpenVPN before 2.3 has no idea what IPv6 is (in client-server mode). In 2.3 (of which beta1 has been released today), IPv4 and IPv6 default redirection have to be done explicitely in the server config, and there is no "give me both!" command yet - so the server admin decides what he wants, and might overlook one or the other. Plus, while IPv6 communication can be redirected to the tunnel (by just pushing a 2000::/3 route), more specific IPv6 routes pointing elsewhere will still be honoured, including "connected /64" networks. To make "--redirect-gateway block-local" (which does "all IPv4 communication MUST go through the server!") work for IPv6 on all supported platforms is quite a bit of work, so it has not yet been done - it's likely to happen for OpenVPN 2.4, but for now the priorities have been "get out 2.3 with at least some basic IPv6 support, well-tested and working across all client platforms". (In the end it's the usual problem of available time in open source projects...) Gert Doering -- OpenVPN IPv6 wrangler -- 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 fgont@si6networks.com Thu Sep 13 16:48: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 56F8921F8620 for ; Thu, 13 Sep 2012 16:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HFfpCmEbrNN for ; Thu, 13 Sep 2012 16:48:41 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B5F9F21F8628 for ; Thu, 13 Sep 2012 16:48:41 -0700 (PDT) Received: from [186.134.45.26] (helo=[192.168.123.129]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TCJ96-0000Fr-5q; Fri, 14 Sep 2012 01:48:32 +0200 Message-ID: <50526975.4020508@si6networks.com> Date: Thu, 13 Sep 2012 20:17:09 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Gert Doering References: <504629E1.9080809@si6networks.com> <504E56FB.3020401@si6networks.com> <5051FB6F.2070204@si6networks.com> <20120913181531.GO13776@Space.Net> In-Reply-To: <20120913181531.GO13776@Space.Net> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 13 Sep 2012 23:48:42 -0000 Hi, Gert, On 09/13/2012 03:15 PM, Gert Doering wrote: > OpenVPN before 2.3 has no idea what IPv6 is (in client-server mode). That's the impression that I got... but since I didn't play much with openvpn (other than getting my vpn "up and running"), I didn't want to make any sort of claim... That said, I get the following banner: OpenVPN 2.2.1 i686-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 30 2012 -- not sure what the PF_INET6 and "IPv6 payload 20110424-2 (2.2RC2)" mean. > Plus, while IPv6 communication can be redirected to the tunnel (by just > pushing a 2000::/3 route), more specific IPv6 routes pointing elsewhere > will still be honoured, including "connected /64" networks. Yes. And there could be default routers with different priorities, too. That's why I had claimed that "even if the vpn software supports v6, the attack might still work". > To make "--redirect-gateway block-local" (which does "all IPv4 communication > MUST go through the server!") Without looking too close into the software, it looks that for the v4 case, openvpn simply installs an additional default route, which for some reason takes precedence over the existing one? > work for IPv6 on all supported platforms is > quite a bit of work, so it has not yet been done - it's likely to happen > for OpenVPN 2.4, but for now the priorities have been "get out 2.3 with > at least some basic IPv6 support, well-tested and working across all > client platforms". So far, I'm simply disabling v6 if I need to rely on the VPN to work as expected/intended. > (In the end it's the usual problem of available time in open source > projects...) Agreed. >From my pov, what's important is to be aware about this issue, and to figure out possible mitigations (even if that's is "turn off v6 if your doing a vpn"). Thanks for the input! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gert@space.net Fri Sep 14 11:14: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 289D921F852C for ; Fri, 14 Sep 2012 11:14:26 -0700 (PDT) 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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2v41NCQ8u4C for ; Fri, 14 Sep 2012 11:14:25 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3736621F84F8 for ; Fri, 14 Sep 2012 11:14:24 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E3734F8DE5 for ; Fri, 14 Sep 2012 20:14:22 +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 92C63F8E20 for ; Fri, 14 Sep 2012 20:14:22 +0200 (CEST) Received: (qmail 64798 invoked by uid 1007); 14 Sep 2012 20:14:22 +0200 Date: Fri, 14 Sep 2012 20:14:22 +0200 From: Gert Doering To: Fernando Gont Message-ID: <20120914181422.GH13776@Space.Net> References: <504629E1.9080809@si6networks.com> <504E56FB.3020401@si6networks.com> <5051FB6F.2070204@si6networks.com> <20120913181531.GO13776@Space.Net> <50526975.4020508@si6networks.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="N0gANzrc4gG6a8qX" Content-Disposition: inline In-Reply-To: <50526975.4020508@si6networks.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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: Fri, 14 Sep 2012 18:14:26 -0000 --N0gANzrc4gG6a8qX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Sep 13, 2012 at 08:17:09PM -0300, Fernando Gont wrote: > On 09/13/2012 03:15 PM, Gert Doering wrote: > > OpenVPN before 2.3 has no idea what IPv6 is (in client-server mode). >=20 > That's the impression that I got... but since I didn't play much with > openvpn (other than getting my vpn "up and running"), I didn't want to > make any sort of claim... >=20 > That said, I get the following banner: > OpenVPN 2.2.1 i686-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] > [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 30 2012 >=20 > -- not sure what the PF_INET6 and "IPv6 payload 20110424-2 (2.2RC2)" mean. That's "you got a debian package that has most of the IPv6 goodies in it already" :-) - both openvpn-over-IPv6 (PF_INET6) and IPv6-over-openvpn have been available as patch sets for about two years now. Debian included them in their package, and I think you could enable it on Gentoo. > > Plus, while IPv6 communication can be redirected to the tunnel (by just= =20 > > pushing a 2000::/3 route), more specific IPv6 routes pointing elsewhere= =20 > > will still be honoured, including "connected /64" networks. >=20 > Yes. And there could be default routers with different priorities, too. >=20 > That's why I had claimed that "even if the vpn software supports v6, the > attack might still work". Yes. Blocking "VPN evasion" traffic for IPv6 is more tricky than for IPv4,= =20 if the hosts supports RAs with more specific routes - even if you block access to the local /64, someone might sneak in a /128 via RA from fe80. I'm really wondering (thinking out loud now) how to block local IPv6 communication in a reasonably portable way... using routing is tricky, using firewalling is even more tricky (as it's optional on all supported operating systems, and the BSDs even have more than one option each...). > > To make "--redirect-gateway block-local" (which does "all IPv4 communic= ation > > MUST go through the server!") >=20 > Without looking too close into the software, it looks that for the v4 > case, openvpn simply installs an additional default route, which for > some reason takes precedence over the existing one? For IPv4, what OpenVPN does depends a bit on the flags given to=20 --redirect-gateway, but there are two possible scenarios: A. - 1. find out what the current default gateway is - 2. install /32 route for OpenVPN server to gateway - 3. delete default route - 4. install default route to tunnel - 5. on disconnect, re-install original default route or B. - 3. override default route with two /1 routes (0.0.0.0/1 and 128/1) in addition, "block-local" does - 3a. find out what the local LAN's netmask is, split into two more-specif= ic subnets, route those into the tunnel (so local connectivity is block= ed by the OpenVPN server dropping those packets) this is not resilient against more-specific IPv4 routes either, but in IPv4, these usually do not happen "magically" by unsolicited packets. =20 > > work for IPv6 on all supported platforms is=20 > > quite a bit of work, so it has not yet been done - it's likely to happe= n=20 > > for OpenVPN 2.4, but for now the priorities have been "get out 2.3 with > > at least some basic IPv6 support, well-tested and working across all > > client platforms". >=20 > So far, I'm simply disabling v6 if I need to rely on the VPN to work as > expected/intended. That can certainly be done, but I'm one of those that *want* to use IPv6, if only to find places of brokenness that need to be fixed :-) Gert Doering -- NetMaster --=20 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 --N0gANzrc4gG6a8qX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBUFNz/qkuBuNlUUl1AQKydQP9HVf+VuKJbD7wB9UcMCLfkT7gknnoBWnx yNM5F6SdWPLbdKfeGALJIXXm2dKnSvLCpV0Pu9hY9Vq2Y0FWLt5Mps8zMcI/0GrR qWFzLxWlH4jOVBvkae1lcWBF31mW8W+s1L7bWdaxd2SeapYK3I/Em1XSzT3YYA9I Q9xjGaK3hN8= =JLId -----END PGP SIGNATURE----- --N0gANzrc4gG6a8qX-- From ietf-secretariat@ietf.org Fri Sep 14 11:17: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 57D6D21F8549; Fri, 14 Sep 2012 11:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgpL5Prv7WQl; Fri, 14 Sep 2012 11:17:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C67921F853E; Fri, 14 Sep 2012 11:17:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120914181713.8337.93189.idtracker@ietfa.amsl.com> Date: Fri, 14 Sep 2012 11:17:13 -0700 X-Mailman-Approved-At: Fri, 14 Sep 2012 11:27:58 -0700 Cc: iaoc@ietf.org, opsec@ietf.org, sidr@ietf.org, v6ops@ietf.org, wgchairs@ietf.org Subject: [OPSEC] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS 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: Fri, 14 Sep 2012 18:17:14 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfre= g.py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations The IETF is holding a block of rooms at the Hotel Okura. The Hotel is not c= urrently ready to accept reservations but we hope to be able to provide boo= king details early next week (the week of 17 September). 3. Meeting Schedule 0900-1700 CEST SIDR 0900-1130 CEST OPSEC 1330-1630 CEST V6OPS From fgont@si6networks.com Fri Sep 14 18:09: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 52CF521F85C6 for ; Fri, 14 Sep 2012 18:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbgNRe5jifYg for ; Fri, 14 Sep 2012 18:09:44 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5537321F85AA for ; Fri, 14 Sep 2012 18:09:44 -0700 (PDT) Received: from [186.134.45.26] (helo=[192.168.0.6]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TCgt5-00023U-4d; Sat, 15 Sep 2012 03:09:35 +0200 Message-ID: <5053D544.3030302@si6networks.com> Date: Fri, 14 Sep 2012 22:09:24 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Gert Doering References: <504629E1.9080809@si6networks.com> <504E56FB.3020401@si6networks.com> <5051FB6F.2070204@si6networks.com> <20120913181531.GO13776@Space.Net> <50526975.4020508@si6networks.com> <20120914181422.GH13776@Space.Net> In-Reply-To: <20120914181422.GH13776@Space.Net> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 15 Sep 2012 01:09:45 -0000 Hi, Gert, On 09/14/2012 03:14 PM, Gert Doering wrote: >> That said, I get the following banner: OpenVPN 2.2.1 >> i686-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] >> [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 30 >> 2012 >> >> -- not sure what the PF_INET6 and "IPv6 payload 20110424-2 >> (2.2RC2)" mean. > > That's "you got a debian package that has most of the IPv6 goodies > in it already" :-) - both openvpn-over-IPv6 (PF_INET6) This means IPv4 packets within IPv6 packets, right? > and IPv6-over-openvpn have been available as patch sets for about > two years now. Debian included them in their package, and I think > you could enable it on Gentoo. Okay. There were no config hints in the sample config file, and hence I assumed no v6 support. >> That's why I had claimed that "even if the vpn software supports >> v6, the attack might still work". > > Yes. Blocking "VPN evasion" traffic for IPv6 is more tricky than > for IPv4, if the hosts supports RAs with more specific routes - > even if you block access to the local /64, someone might sneak in a > /128 via RA from fe80. ... and there's also ICMPv6 Redirect. > I'm really wondering (thinking out loud now) how to block local > IPv6 communication in a reasonably portable way... using routing is > tricky, using firewalling is even more tricky (as it's optional on > all supported operating systems, and the BSDs even have more than > one option each...). Thinking out loud, maybe using sysctl for disabling RA acceptance would do the trick. However: 1) This wouldn't prevent the scenario in which the victim receives the malicious RAs before the vpn software is run. 2) I'd hope nodes ignore ICMPv6 redirects when there's no default router -- but I haven't double-checked this. 3) When working on our IPv6 toolkit (http://www.si6ntworks.com/tools), I was trying to find a portable way f obtaining the list of IPv6 addresses. While considering possible options, I recall reading that use of sysctl was deprecated for Linux -- and hence this might make this option less desirable. 4) This might not apply to other UNIX'es (e.g., Solaris), and of course wouldn't apply to Windows. BTW, I'm interested on the subject, so please keep me posted if you come up with something to fix this issue. >>> To make "--redirect-gateway block-local" (which does "all IPv4 >>> communication MUST go through the server!") >> >> Without looking too close into the software, it looks that for >> the v4 case, openvpn simply installs an additional default route, >> which for some reason takes precedence over the existing one? > > For IPv4, what OpenVPN does depends a bit on the flags given to > --redirect-gateway, but there are two possible scenarios: > > A. - 1. find out what the current default gateway is - 2. install > /32 route for OpenVPN server to gateway - 3. delete default route - > 4. install default route to tunnel - 5. on disconnect, re-install > original default route > > or B. - 3. override default route with two /1 routes (0.0.0.0/1 and > 128/1) What about ICMP redirects? > in addition, "block-local" does - 3a. find out what the local LAN's > netmask is, split into two more-specific subnets, route those into > the tunnel (so local connectivity is blocked by the OpenVPN server > dropping those packets) > > this is not resilient against more-specific IPv4 routes either, but > in IPv4, these usually do not happen "magically" by unsolicited > packets. Same here: What about ICMP redirects? (which could trigger these) >>> work for IPv6 on all supported platforms is quite a bit of >>> work, so it has not yet been done - it's likely to happen for >>> OpenVPN 2.4, but for now the priorities have been "get out 2.3 >>> with at least some basic IPv6 support, well-tested and working >>> across all client platforms". >> >> So far, I'm simply disabling v6 if I need to rely on the VPN to >> work as expected/intended. > > That can certainly be done, but I'm one of those that *want* to use > IPv6, if only to find places of brokenness that need to be fixed > :-) Agreed. I'm just saying that, given the current state of affairs, being vulnerable to this kind of attack is unacceptable to me (that's why I'm doing the VPN in the first place), and hence this solves the problem for me (albeit not in the most desirable way). Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gert@space.net Sat Sep 15 00:21:41 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 8692A21F85A8 for ; Sat, 15 Sep 2012 00:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.969 X-Spam-Level: X-Spam-Status: No, score=-1.969 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l+b33Mt88NlN for ; Sat, 15 Sep 2012 00:21:40 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 976BB21F85A7 for ; Sat, 15 Sep 2012 00:21:39 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 1737CF8DF4 for ; Sat, 15 Sep 2012 09:21:38 +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 E20B9F8DD5 for ; Sat, 15 Sep 2012 09:21:37 +0200 (CEST) Received: (qmail 91241 invoked by uid 1007); 15 Sep 2012 09:21:37 +0200 Date: Sat, 15 Sep 2012 09:21:37 +0200 From: Gert Doering To: Fernando Gont Message-ID: <20120915072137.GM13776@Space.Net> References: <504629E1.9080809@si6networks.com> <504E56FB.3020401@si6networks.com> <5051FB6F.2070204@si6networks.com> <20120913181531.GO13776@Space.Net> <50526975.4020508@si6networks.com> <20120914181422.GH13776@Space.Net> <5053D544.3030302@si6networks.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0m8kGjhpcdGkboP1" Content-Disposition: inline In-Reply-To: <5053D544.3030302@si6networks.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 15 Sep 2012 07:21:41 -0000 --0m8kGjhpcdGkboP1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Sep 14, 2012 at 10:09:24PM -0300, Fernando Gont wrote: > On 09/14/2012 03:14 PM, Gert Doering wrote: > >> That said, I get the following banner: OpenVPN 2.2.1 > >> i686-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [eurephia] [MH] > >> [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Mar 30 > >> 2012 > >>=20 > >> -- not sure what the PF_INET6 and "IPv6 payload 20110424-2 > >> (2.2RC2)" mean. > >=20 > > That's "you got a debian package that has most of the IPv6 goodies > > in it already" :-) - both openvpn-over-IPv6 (PF_INET6) >=20 > This means IPv4 packets within IPv6 packets, right? No, that one is OpenVPN within IPv6 packets (using IPv6 transport). Which is something that "stock" OpenVPN 2.2 also did not do yet. IPv4 packets within IPv6 is "IPv6 payload". (In the end it just says "both patch sets that are needed to provide=20 basic IPv6 support on the outside and inside are in" - it's two different patch sets because they were developed by different persons. 2.3 will=20 only say [IPv6] here) > >> That's why I had claimed that "even if the vpn software supports > >> v6, the attack might still work". > >=20 > > Yes. Blocking "VPN evasion" traffic for IPv6 is more tricky than > > for IPv4, if the hosts supports RAs with more specific routes - > > even if you block access to the local /64, someone might sneak in a > > /128 via RA from fe80. >=20 > ... and there's also ICMPv6 Redirect. And that, yes. > > I'm really wondering (thinking out loud now) how to block local > > IPv6 communication in a reasonably portable way... using routing is > > tricky, using firewalling is even more tricky (as it's optional on > > all supported operating systems, and the BSDs even have more than > > one option each...). >=20 > Thinking out loud, maybe using sysctl for disabling RA acceptance > would do the trick. Certainly easier than fiddling with the firewall settings, yes. > However: >=20 > 1) This wouldn't prevent the scenario in which the victim receives the > malicious RAs before the vpn software is run. That one could be handled as we do today for IPv4 - "get a list of=20 pre-existing routes, store away, delete all routes, install /128 route for OpenVPN server's address, route default through tunnel". After the end of OpenVPN, restore routing state. This might still be messy, as routes that started as "RA installed" could then end up being "static". Mmmh. > 2) I'd hope nodes ignore ICMPv6 redirects when there's no default > router -- but I haven't double-checked this. I'd hope that an implementation would ignore ICMPv6 redirects coming =66rom something that is not the gateway for the prefix in question. But that's wishful thinking, haven't tested. > 3) When working on our IPv6 toolkit (http://www.si6ntworks.com/tools), > I was trying to find a portable way f obtaining the list of IPv6 > addresses. While considering possible options, I recall reading that > use of sysctl was deprecated for Linux -- and hence this might make > this option less desirable. On Linux, OpenVPN 2.4 is very likely to use the netlink socket interface for routing table manipulation and IP address querying. On the BSDs,=20 something similar will have to be found. This part of OpenVPN is already very system specific, exec'ing "ifconfig" and "route" to do its job - as no two operating systems use the same syntax for either... > 4) This might not apply to other UNIX'es (e.g., Solaris), and of > course wouldn't apply to Windows. Windows "Vista and up" *does* have fairly nice APIs for controlling=20 IPv6 routing :-) - OpenVPN currently does not use them (uses netsh.exe instead) because XP doesn't have these APIs yet... > BTW, I'm interested on the subject, so please keep me posted if you > come up with something to fix this issue. Will send a heads up. [..] > > For IPv4, what OpenVPN does depends a bit on the flags given to=20 > > --redirect-gateway, but there are two possible scenarios: [..] > Same here: What about ICMP redirects? (which could trigger these) Good question. I think they are currently not handled as all, as they would be considered "pre-existing route". Wether operating systems honour IPv4 ICMP redirects from routers that are not the current target of the route anyway stands to be tested, as for IPv6. Hopefully not... > >>> work for IPv6 on all supported platforms is quite a bit of > >>> work, so it has not yet been done - it's likely to happen for > >>> OpenVPN 2.4, but for now the priorities have been "get out 2.3 > >>> with at least some basic IPv6 support, well-tested and working > >>> across all client platforms". > >>=20 > >> So far, I'm simply disabling v6 if I need to rely on the VPN to > >> work as expected/intended. > >=20 > > That can certainly be done, but I'm one of those that *want* to use > > IPv6, if only to find places of brokenness that need to be fixed > > :-) >=20 > Agreed. I'm just saying that, given the current state of affairs, > being vulnerable to this kind of attack is unacceptable to me (that's > why I'm doing the VPN in the first place), and hence this solves the > problem for me (albeit not in the most desirable way). Understood. Gert Doering -- NetMaster --=20 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 --0m8kGjhpcdGkboP1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBUFQsgakuBuNlUUl1AQLN/gQAwfjLbPiHHbjXGmeNLRGS7PDryYneRLbt Ozv38zBROmDuArmcuWYgp4N5JXusu40CmyfZIljMs57cY3nQDgvObNdepHv/Xa6I 2AwO6DdzbhA7YzQ1ouyQ4Nz/OZmjl1xZv74DjDDd8ZpHm18ibmiAJqjBZ8lsZ28Y Gag6rlte4iU= =4XSe -----END PGP SIGNATURE----- --0m8kGjhpcdGkboP1-- From fgont@si6networks.com Sat Sep 15 09:06:12 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 0B85A21F84F2 for ; Sat, 15 Sep 2012 09:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.124 X-Spam-Level: X-Spam-Status: No, score=-2.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujZN5HhotrgH for ; Sat, 15 Sep 2012 09:06:11 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFDA21F84F0 for ; Sat, 15 Sep 2012 09:06:10 -0700 (PDT) Received: from [186.134.11.174] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TCusc-0000VQ-Vt; Sat, 15 Sep 2012 18:06:03 +0200 Message-ID: <505487F5.7020904@si6networks.com> Date: Sat, 15 Sep 2012 10:51:49 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: Gert Doering References: <504629E1.9080809@si6networks.com> <504E56FB.3020401@si6networks.com> <5051FB6F.2070204@si6networks.com> <20120913181531.GO13776@Space.Net> <50526975.4020508@si6networks.com> <20120914181422.GH13776@Space.Net> <5053D544.3030302@si6networks.com> <20120915072137.GM13776@Space.Net> In-Reply-To: <20120915072137.GM13776@Space.Net> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 15 Sep 2012 16:06:12 -0000 On 09/15/2012 04:21 AM, Gert Doering wrote: >> 1) This wouldn't prevent the scenario in which the victim >> receives the malicious RAs before the vpn software is run. > > That one could be handled as we do today for IPv4 - "get a list of > pre-existing routes, store away, delete all routes, install /128 > route for OpenVPN server's address, route default through tunnel". > After the end of OpenVPN, restore routing state. > > This might still be messy, as routes that started as "RA > installed" could then end up being "static". Mmmh. You mean that those routes that started as dynamic would be reinstalled as "static" because of the API you're using to reinstall them? Wouldn't it be possible to reinstall them as dynamic, using the same interface that, say, radvd uses? >> 2) I'd hope nodes ignore ICMPv6 redirects when there's no >> default router -- but I haven't double-checked this. > > I'd hope that an implementation would ignore ICMPv6 redirects > coming from something that is not the gateway for the prefix in > question. But that's wishful thinking, haven't tested. Same here. >> 3) When working on our IPv6 toolkit >> (http://www.si6ntworks.com/tools), I was trying to find a >> portable way f obtaining the list of IPv6 addresses. While >> considering possible options, I recall reading that use of sysctl >> was deprecated for Linux -- and hence this might make this >> option less desirable. > > On Linux, OpenVPN 2.4 is very likely to use the netlink socket > interface for routing table manipulation and IP address querying. Why not "routng sockets"? > On the BSDs, something similar will have to be found. BTW, while looking at these, I wasn't able to find any documentation for IPv6 routing sockets -- were you? >> 4) This might not apply to other UNIX'es (e.g., Solaris), and of >> course wouldn't apply to Windows. > > Windows "Vista and up" *does* have fairly nice APIs for controlling > IPv6 routing :-) I wasn't aware of this -- but nevertheless I was simply noting that most likely Windows does not support syscctl as we know it from the UNIX world? > [..] >>> For IPv4, what OpenVPN does depends a bit on the flags given to >>> --redirect-gateway, but there are two possible scenarios: > [..] >> Same here: What about ICMP redirects? (which could trigger >> these) > > Good question. I think they are currently not handled as all, as > they would be considered "pre-existing route". Not sure what you mean... > Wether operating systems honour IPv4 ICMP redirects from routers > that are not the current target of the route anyway stands to be > tested, as for IPv6. Hopefully not... Will try this and report back. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From gert@space.net Mon Sep 17 04:46:28 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 69F6421F8629 for ; Mon, 17 Sep 2012 04:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ACcS35hC3iAK for ; Mon, 17 Sep 2012 04:46:27 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEB421F8625 for ; Mon, 17 Sep 2012 04:46:26 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E4BFFF8CAD for ; Mon, 17 Sep 2012 13:46:24 +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 B80CCF8C79 for ; Mon, 17 Sep 2012 13:46:24 +0200 (CEST) Received: (qmail 54448 invoked by uid 1007); 17 Sep 2012 13:46:24 +0200 Date: Mon, 17 Sep 2012 13:46:24 +0200 From: Gert Doering To: Fernando Gont Message-ID: <20120917114624.GV13776@Space.Net> References: <504E56FB.3020401@si6networks.com> <5051FB6F.2070204@si6networks.com> <20120913181531.GO13776@Space.Net> <50526975.4020508@si6networks.com> <20120914181422.GH13776@Space.Net> <5053D544.3030302@si6networks.com> <20120915072137.GM13776@Space.Net> <505487F5.7020904@si6networks.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0eteEYkd2ASGrJNt" Content-Disposition: inline In-Reply-To: <505487F5.7020904@si6networks.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "'opsec@ietf.org'" Subject: Re: [OPSEC] IPv6 implications on IPv4 nets: IPv6 RAs, IPv4's VPN "leakage" 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, 17 Sep 2012 11:46:28 -0000 --0eteEYkd2ASGrJNt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Sep 15, 2012 at 10:51:49AM -0300, Fernando Gont wrote: > > That one could be handled as we do today for IPv4 - "get a list of > > pre-existing routes, store away, delete all routes, install /128 > > route for OpenVPN server's address, route default through tunnel". > > After the end of OpenVPN, restore routing state. > >=20 > > This might still be messy, as routes that started as "RA > > installed" could then end up being "static". Mmmh. >=20 > You mean that those routes that started as dynamic would be > reinstalled as "static" because of the API you're using to reinstall them? Yep... > Wouldn't it be possible to reinstall them as dynamic, using the same > interface that, say, radvd uses? =2E.. if that interface exists, yet. RA and ICMP redirects are handled by= =20 the kernel internally, so userland might not be able to re-install such a route at all. I'm currently pondering "ip rule" for this - just set up a separate=20 routing table that only has two routes "VPN-Gateway to old default GW, default to OpenVPN tunnel" and force all packets there via "ip rule" - so no matter what was in the routing table before OpenVPN starts, or is added while it runs, it won't be used unless it's in that particular table (not safe against a malicious + clueful root user on the same box,=20 though). The terminology used shows that I have only toyed with the Linux approach to things, but OpenBSD and FreeBSD have multiple routing tables as well, so something along that line might be possible there, too. No idea about Windows. > >> 3) When working on our IPv6 toolkit > >> (http://www.si6ntworks.com/tools), I was trying to find a > >> portable way f obtaining the list of IPv6 addresses. While > >> considering possible options, I recall reading that use of sysctl > >> was deprecated for Linux -- and hence this might make this > >> option less desirable. > >=20 > > On Linux, OpenVPN 2.4 is very likely to use the netlink socket > > interface for routing table manipulation and IP address querying. >=20 > Why not "routng sockets"? I think I was thinking "routing sockets". Haven't fully understood which bits are called "routing socket" and which bits are "netlink socket", but the intention is "the API that is used by programs like 'route' or 'ifconfig' under the hood". > > On the BSDs, something similar will have to be found. >=20 > BTW, while looking at these, I wasn't able to find any documentation > for IPv6 routing sockets -- were you? Didn't go hunting yet. I plan to start by reading the source code for ifconfig and route... :-) > >> 4) This might not apply to other UNIX'es (e.g., Solaris), and of=20 > >> course wouldn't apply to Windows. > >=20 > > Windows "Vista and up" *does* have fairly nice APIs for controlling > > IPv6 routing :-) >=20 > I wasn't aware of this -- but nevertheless I was simply noting that > most likely Windows does not support syscctl as we know it from the > UNIX world? No, windows would do "something else". I'm not a windows programmer,=20 so I'd ask one of the other OpenVPN team members who is planning to overhaul the whole privilege architecture of OpenVPN-on-Windows for 2.4... :) > > [..] > >>> For IPv4, what OpenVPN does depends a bit on the flags given to > >>> --redirect-gateway, but there are two possible scenarios: > > [..] > >> Same here: What about ICMP redirects? (which could trigger > >> these) > >=20 > > Good question. I think they are currently not handled as all, as > > they would be considered "pre-existing route". >=20 > Not sure what you mean... I think OpenVPN doesn't currently handle any routes that are in the routing table before OpenVPN starts and are not "the default route" or=20 "the local LAN route" - they will just stay around. ICMP redirects would fall into the same bin. > > Wether operating systems honour IPv4 ICMP redirects from routers > > that are not the current target of the route anyway stands to be > > tested, as for IPv6. Hopefully not... > Will try this and report back. I'm very curious to hear about your findings :) Gert Doering -- NetMaster --=20 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 --0eteEYkd2ASGrJNt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iQCVAwUBUFcNkKkuBuNlUUl1AQKkyAP9E4MOwtLoAMPofolwzvsG+fHEh5+CJog2 wblHBlBznB0ItbEFyY+DcqMunlUt7zDYalSnfdh9kZ+EdGQKHAvMvwbNQsIoryH9 urHRqw27KKZ0UmLSjbexPJmLfyMkcBdiJW91YJ8qA1MLmI2NzTf16djspZSUhHk/ kxBKZj3//Ow= =CVki -----END PGP SIGNATURE----- --0eteEYkd2ASGrJNt-- From ietf-secretariat@ietf.org Mon Sep 17 12:56:20 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 B54F821E8044; Mon, 17 Sep 2012 12:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4UhwGWYibXz; Mon, 17 Sep 2012 12:56:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3640221E8037; Mon, 17 Sep 2012 12:56:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120917195620.22823.34712.idtracker@ietfa.amsl.com> Date: Mon, 17 Sep 2012 12:56:20 -0700 X-Mailman-Approved-At: Mon, 17 Sep 2012 13:25:58 -0700 Cc: iaoc@ietf.org, opsec@ietf.org, sidr@ietf.org, v6ops@ietf.org, wgchairs@ietf.org Subject: [OPSEC] IETF Large Interim Meeting - Accommodations Information 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, 17 Sep 2012 19:56:20 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations - Information now available! 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfre= g.py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations A block of rooms is being held at the Hotel Okura Amsterdam (meeting ve= nue) for the nights of September 28 and 29. Rate: 195 EUR [256 USD; 20,065 JPY] Rate includes breakfast and guest room wireless internet. To make your reservation on line, please go to: www.okura.nl Group Code: IETF2012 Reservations cut-off date: 21 September 2012 Guest Cancellation: - Reservations may=C2=A0be changed up to 1 week prior to the event with= out penalty. - 50% of reservation value penalty for cancellation less than 14 days a= nd greater than 7 days prior to event. - 80% of reservation value penalty for cancellation less than 7 days an= d greater than 3 days prior to event. - 100% of reservation value penalty for cancellation less than 3 days p= rior to event or non-arrival or no-show. - In case of early departure, the full value of the reservation will be= charged to the guest. If you have any problems making your reservation, please send a message to = agenda@ietf.org 3. Meeting Schedule 0900-1700 CEST SIDR 0900-1130 CEST OPSEC 1330-1630 CEST V6OPS From ietf-secretariat@ietf.org Tue Sep 18 12:01:58 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 6F9D821E8103; Tue, 18 Sep 2012 12:01:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.315 X-Spam-Level: X-Spam-Status: No, score=-102.315 tagged_above=-999 required=5 tests=[AWL=-0.316, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bE2gWA4GHP33; Tue, 18 Sep 2012 12:01:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FA221E80C1; Tue, 18 Sep 2012 12:01:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120918190157.21518.15763.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2012 12:01:57 -0700 X-Mailman-Approved-At: Tue, 18 Sep 2012 18:31:51 -0700 Cc: iaoc@ietf.org, opsec@ietf.org, sidr@ietf.org, v6ops@ietf.org, wgchairs@ietf.org Subject: [OPSEC] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS 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, 18 Sep 2012 19:01:58 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations - Reservations Cutoff: 21 September 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfreg= .py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations A block of rooms is being held at the Hotel Okura Amsterdam (meeting ven= ue) for the nights of September 28 and 29. Rate: 195 EUR [256 USD; 20,065 JPY] Rate includes breakfast and guest room wireless internet but excludes = 5% city tax. To make your reservation on line, please go to: www.okura.nl Group Code: IETF2012 Reservations cut-off date: 21 September 2012 Guest Cancellation: - Reservations may be changed up to 1 week prior to the event without pe= nalty. (You can change, not cancel, the reservation, i.e. change arrival, departure dates or name, up to 1 week without penalty but not cancel the reservation without penalty.) - 50% of reservation value penalty for cancellation less than 14 days an= d greater than 7 days prior to event. If you cancel, not change, the reserv= ation less than 14 days but more than 7 days prior to the event you will be= charged 50% of the total reservation fee. - 80% of reservation value penalty for cancellation less than 7 days and= greater than 3 days prior to event. If you cancel, not change, the reserva= tion less than 7 days prior to the event you will be charged 80% of the tot= al reservation fee. - 100% of reservation value penalty for cancellation less than 3 days pr= ior to event or non-arrival or no-show. - In case of early departure, the full value of the reservation will be = charged to the guest. If you have any problems making your reservation, please send a message to = agenda@ietf.org 3. Meeting Schedule 0900-1700 CEST SIDR 0900-1130 CEST OPSEC 1330-1630 CEST V6OPS From kkumar@google.com Tue Sep 18 21:01: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 59F9921E8084 for ; Tue, 18 Sep 2012 21:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZrfJSislTzN for ; Tue, 18 Sep 2012 21:01:58 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23E0521F8456 for ; Tue, 18 Sep 2012 21:01:57 -0700 (PDT) Received: by lboj14 with SMTP id j14so22803lbo.31 for ; Tue, 18 Sep 2012 21:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=dJPIaaiT0sxM3xc6dbETYQnyDj8pkk93hwz7qs1Cl+8=; b=onf7ZoFMX40CO4UbReiXoAeGFDpHavTVvLE9DCs7FTtC6pLAEdLgGacmZpm41V0XSe acVli5g3hHI3plmPM2a+uY9CrBTiTWmQJ5GItgRHZzP5XybqRXGZLwumSpMxBJOdsiOz S3/GvKaUYrIXKTRXbQnW8zhpXqVjpQ+FdIs3D84ogYcipqwYB1UoZM4jALIpb0eRPk8E NmH56NmFgBMQUF3UNgbPHztA3R+HkRfwLhLGOtP8FQg3C9bDT6VG6A24KBkfmKKta5kn GyU/zummXVY+GYdM/ctqomCL/TJQGR4QyUF4y7Cei5BtzR9aVVN7qlB6fgcVT8WUN4jN SvKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=dJPIaaiT0sxM3xc6dbETYQnyDj8pkk93hwz7qs1Cl+8=; b=gjsbVz2DOpo6Eo19hwOGeD5I68wa18/ZzMVv7oFGn8f/Jf+UXDnacl9Kz/S0qg72kT bF2FhDjzPWGgwdfXbsdE4mXzAX70MfqcGTgtA0c7Q8Uw0sTzVJRv7YfqlWHvpAxvhgK1 pxpl3qLGp4nYgNLcwBKCyjYHjvMFB8NUgpRMxLpxSz2DfEDTBOm6EUmtgwgtAaKgO5py j2WdtruCPGwuxfWiIBMn8hZzekAHEJvaHTmBWjELC3z5K7uayWLqJ8wt27y3REFz2NYx ZMjIdrAWYorP3MrrNfW6SSsJtqenCQA0mz5lP9FJln6mrLT+wH/V0t6yBNdKaqnn3zqu f1pg== Received: by 10.112.101.194 with SMTP id fi2mr567737lbb.104.1348027316949; Tue, 18 Sep 2012 21:01:56 -0700 (PDT) Received: by 10.112.101.194 with SMTP id fi2mr567726lbb.104.1348027316685; Tue, 18 Sep 2012 21:01:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.66.42 with HTTP; Tue, 18 Sep 2012 21:01:35 -0700 (PDT) In-Reply-To: References: From: KK Date: Tue, 18 Sep 2012 21:01:35 -0700 Message-ID: To: opsec@ietf.org Content-Type: multipart/alternative; boundary=f46d040169b55bc9d804ca061128 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnOFEh7qnjG1k0Ergs3ExgnCnt2oAk/UlZu5Hx2jh+Q/XA73eNtQlSVz7GDypmcXE2jJmOc77PhE3s3i6ZI1MznxjM308t5EEhS8dgM+2FFSQo/j4dtDwCXh5KUfTIMYlALvcVnb4vY6x5xCHwuWQ2Auh1QV9syac0oaTKAMhq3Ntn3i8dWt0Xo54IHWzibERYn37ir Cc: "opsec-chairs@ietf.org" Subject: Re: [OPSEC] OPSEC Interim Meeting Announcement - Sep 29th 2012 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: Wed, 19 Sep 2012 04:01:59 -0000 --f46d040169b55bc9d804ca061128 Content-Type: text/plain; charset=ISO-8859-1 Hey Folks, Just a quick reminder - if you would like a slot at the Interim, please submit your drafts by 23:59 UTC, Sep 21, 2012. Thanks, KK, Gunter, Warren On Tue, Aug 21, 2012 at 2:07 PM, KK wrote: > Hello Everyone, > > OPSEC is going to hold an interim meeting in Amsterdam, right after > the end of RIPE 65 , on Sep 29th, 2012. The > meeting will be held in the same hotel as the RIPE meeting: > > Hotel Okura > > Ferdinand Bolstraat 333 > 1072 LH Amsterdam > +31 (0) 20 678 7493 > > Meeting time TBD. > > Here, we would discuss drafts that have been updated or posted no > later than a week in advance of the interim. Therefore, I would > request that you submit your drafts by 23:59 UTC, Sep 21, 2012 > > Thanks, > KK, Gunter, Warren > --f46d040169b55bc9d804ca061128 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Folks,

Just a quick reminder - if you would like a s= lot at the Interim, please submit your drafts by 23:59 UTC, Sep 21, 2012.

Thanks,
KK, Gunter, Warren


On Tue, Aug 21, 2012 at 2:07 PM, KK <kk@goo= gle.com> wrote:
Hello Everyone,

OPSEC is going to hold an interim meeting in Amsterdam, right after
the end of RIPE 65 <https://ripe65.ripe.net/>, on Sep 29th, 2012. =A0The
meeting will be held in the same hotel as the RIPE meeting:

Hotel Okura <http://w= ww.okura.nl/>

Ferdinand Bolstraat 333
1072 LH Amsterdam
+3= 1 (0) 20 678 7493

Meeting time TBD.

Here, we would discuss drafts that have been updated or posted no
later than a week in advance of the interim. Therefore, I would
request that you submit your drafts by 23:59 UTC, Sep 21, 2012

Thanks,
KK, Gunter, Warren

--f46d040169b55bc9d804ca061128-- From internet-drafts@ietf.org Fri Sep 21 09:04: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 A55C921E80B6; Fri, 21 Sep 2012 09:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkprhvXcQcGu; Fri, 21 Sep 2012 09:04:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4899521E803D; Fri, 21 Sep 2012 09:04:17 -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.34 Message-ID: <20120921160417.18679.41003.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 09:04:17 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-01.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: Fri, 21 Sep 2012 16:04:17 -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 : Using Only Link-Local Addressing Inside an IPv6 Network Author(s) : Michael Behringer Eric Vyncke Filename : draft-ietf-opsec-lla-only-01.txt Pages : 8 Date : 2012-09-21 Abstract: In an IPv6 network it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to help the decision process for a given network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-lla-only-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf-secretariat@ietf.org Fri Sep 21 06:17:47 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 1193C21F880C; Fri, 21 Sep 2012 06:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbnflMjE5-O5; Fri, 21 Sep 2012 06:17:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E19421F87E5; Fri, 21 Sep 2012 06:17:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120921131746.9793.61038.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 06:17:46 -0700 X-Mailman-Approved-At: Fri, 21 Sep 2012 10:00:20 -0700 Cc: iaoc@ietf.org, opsec@ietf.org, sidr@ietf.org, v6ops@ietf.org, wgchairs@ietf.org Subject: [OPSEC] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS 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: Fri, 21 Sep 2012 13:17:47 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations - Reservations Cutoff: 21 September 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfreg.= py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations A block of rooms is being held at the Hotel Okura Amsterdam (meeting venu= e) for the nights of September 28 and 29. Rate: 195 EUR [256 USD; 20,065 JPY] Rate includes breakfast and guest room wireless internet but excludes 5= % city tax. To make your reservation on line, please go to: www.okura.nl Group Code: IETF2012 Reservations cut-off date: 21 September 2012 Guest Cancellation: - Reservations may be changed up to 1 week prior to the event without pen= alty. (You can change, not cancel, the reservation, i.e. change arrival, departure dates or name, up to 1 week without penalty but not cancel the reservation without penalty.) - 50% of reservation value penalty for cancellation less than 14 days and= greater than 7 days prior to event. If you cancel, not change, the reserva= tion less than 14 days but more than 7 days prior to the event you will be = charged 50% of the total reservation fee. - 80% of reservation value penalty for cancellation less than 7 days and = greater than 3 days prior to event. If you cancel, not change, the reservat= ion less than 7 days prior to the event you will be charged 80% of the tota= l reservation fee. - 100% of reservation value penalty for cancellation less than 3 days pri= or to event or non-arrival or no-show. - In case of early departure, the full value of the reservation will be c= harged to the guest. If you have any problems making your reservation, please send a message to = agenda@ietf.org 3. Meeting Schedule 0900-1700 CEST SIDR 0900-1130 CEST OPSEC 1330-1630 CEST V6OPS From internet-drafts@ietf.org Fri Sep 21 10:04:58 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 6F09F21F8781; Fri, 21 Sep 2012 10:04:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8Dh0OzsMcaa; Fri, 21 Sep 2012 10:04:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0232321F875C; Fri, 21 Sep 2012 10:04:58 -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.34 Message-ID: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 10:04:58 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-v6-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: Fri, 21 Sep 2012 17:04:58 -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 : Operational Security Considerations for IPv6 Networks Author(s) : Kiran Kumar Chittimaneni Merike Kaeo Eric Vyncke Filename : draft-ietf-opsec-v6-00.txt Pages : 36 Date : 2012-09-21 Abstract: Network managers know how to operate securely IPv4 network: whether it is the Internet or an enterprise internal network. IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol but network managers need also a more practical, operation-minded best common practices. This document analyzes the operational security issues in all places of a network (service providers, enterprises and residential users) and proposes technical and procedural mitigations techniques. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-v6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-v6-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kkumar@google.com Mon Sep 24 08:39: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 509B621F87E0 for ; Mon, 24 Sep 2012 08:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stXfhUtnChJW for ; Mon, 24 Sep 2012 08:39:58 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D74521F87DD for ; Mon, 24 Sep 2012 08:39:58 -0700 (PDT) Received: by lbok13 with SMTP id k13so1191812lbo.31 for ; Mon, 24 Sep 2012 08:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record; bh=GtS0pO62HNu7Sge7BnepHQyyjG8F0yFjkQORDMA5K6w=; b=GInSwIq09zGhRPcYWTj8wgIr0l0kHHGopxEDj9LUSJOuHPOk+OICt/SxHomJ9PP/jw qx4bd0T7XTZg0H08qWwBL5bX6XR0W5g4OZ+Xoht3mFfP12D3m+uQIA1/GdNrF+i+nxLW /PPqsLTpK9TpNIH1zOMsfRtiGMySIPot0Ll4bqf88y+VIemqz2JIGDQvGs7w8kRIUcGw xrl29m5jrcFs4g4uccVos4VR0BnvMUGcyWX0DLHcE1KLmE7Lh1+We33X01hDhNHOl467 AHnbLhlFV2zMArzMcrEmsFVG4yhuglueITMWZZkxmce8dJxylv2HSe4a6PFrZOFSoxdt XzVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=GtS0pO62HNu7Sge7BnepHQyyjG8F0yFjkQORDMA5K6w=; b=eDK1thR3Z57y3xk8J1MvtNsNBsLnTilPqPW7d1Cln4tBCYOR2j1pbJbEmQy2lyEXfH BgX5l7zKSiNJuaPWGANJSmoiQy/oCgPRc7G5WImpq5ZJR/6E7dFIrjHvf/znFSbYRjgD 5X7pwVG8lCt42fmGj3fxPmYpYfW1oJKpb2VzdOUGUIDSvbgELxMVbouB0xbNKQbsSy71 79xA/A+BSK9A7gWwfGzyxEVwFF9JFW1GNIuMxjDflSRrqdDt9Q2lnpAKaXGrI/QnkXnO etFmdkRReOzZo6jeByT/ELlafYI/5kmaOEiZBGDEyFlDE6S2IOrUGA9AwBUtetG7mu/o cPLw== Received: by 10.152.105.206 with SMTP id go14mr10767178lab.37.1348501197089; Mon, 24 Sep 2012 08:39:57 -0700 (PDT) Received: by 10.152.105.206 with SMTP id go14mr10767170lab.37.1348501196952; Mon, 24 Sep 2012 08:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.66.42 with HTTP; Mon, 24 Sep 2012 08:39:36 -0700 (PDT) From: KK Date: Mon, 24 Sep 2012 08:39:36 -0700 Message-ID: To: opsec@ietf.org Content-Type: multipart/alternative; boundary=f46d04071173d2d45704ca746619 X-System-Of-Record: true X-Gm-Message-State: ALoCoQli8EkzPUDmBjEO1Q69gRePjoz2tR3PMenewpeVdeliLbWoJmuEuUKvTkNDMyC3eZJ0t/aNVDpSmKLu8E87fY3oyz+Ec2mivJ1SAVCAFjTR6boAddf1IHHY7EYrZFNQN42hOLIDnXDdIpZo4b17U7j1qzu5tNv/U4fSQPotthE2HVPiAI9EN+EGZgmSoP2V0Mqlsa8S Cc: "opsec-chairs@ietf.org" Subject: [OPSEC] Draft Agenda for Large Interim Meeting in Amsterdam 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, 24 Sep 2012 15:39:59 -0000 --f46d04071173d2d45704ca746619 Content-Type: text/plain; charset=ISO-8859-1 Hey Folks, A draft agenda has been posted on the website. For your convenience, I have pasted the text below. """ Operational Security Capabilities for IP Network Infrastructure - IETF Large Interim Meeting, Amsterdam Saturday, Sep 29, 09:00 - 11:30 Room: TBD ----------------------- Administrivia, Agenda Bashing, 10 Minutes Operational Security Considerations for IPv6 Networks draft-ietf-opsec-v6-00 , 30 minutes BGP Operations and Security draft-jdurand-bgp-security-01, 30 Minutes Using Only Link-Local Addressing Inside an IPv6 Network draft-ietf-opsec-lla-only-01, 10 Minutes Passive IP addresses draft-baker-opsec-passive-ip-address-00 , 15 minutes """ We will be posting details on remote participation once we confirm that information. Please let me know if you would still like a slot to present. Thanks, KK, Gunter, Warren --f46d04071173d2d45704ca746619 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Folks,

A draft agenda has been posted on the website. For your convenience, = I have pasted the text below.

"""

Operational Security Capabilities for IP Network Infrastruc= ture - IETF Large Interim Meeting, Amsterdam
=A0 =A0 =A0 =A0 =A0

Saturday, Sep 29, = 09:00 - 11:30

Room: TBD
-----------------------
Admi= nistrivia, Agenda Bashing, 10 Minutes

Operat= ional Security Considerations for IPv6 Networks
draft-ietf-o= psec-v6-00, 30 minutes

BGP Operations and Security

draft-jdurand-bgp-secu= rity-01, 30 Minutes

Using Only Link-Local Addressing Inside an I= Pv6 Network
draft-ietf-opsec-lla-only-01, 10 Minutes

Passive IP addresses

draft-baker-opsec-p= assive-ip-address-00,=A015 minutes


"""


We will be posting details= on remote participation once we confirm that information.=A0Please let me know if you would still = like a slot to present.


Thanks,

KK, Gunter, Warren

--f46d04071173d2d45704ca746619-- From ietf-secretariat@ietf.org Wed Sep 26 08:07:06 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 F163F21F8658; Wed, 26 Sep 2012 08:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.242 X-Spam-Level: X-Spam-Status: No, score=-102.242 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3PS-G0yrdGj; Wed, 26 Sep 2012 08:07:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8087F21F84C4; Wed, 26 Sep 2012 08:07:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: opsec@ietf.org, v6ops@ietf.org, sidr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120926150705.8596.75260.idtracker@ietfa.amsl.com> Date: Wed, 26 Sep 2012 08:07:05 -0700 Subject: [OPSEC] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS 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: Wed, 26 Sep 2012 15:07:06 -0000 OPSEC, SIDR and V6OPS Interim Meeting Amsterdam, The Netherlands 29 September 2012 Venue: Hotel Okura Amsterdam (www.okura.nl) Ferdinand Bolstraat 333 1072 LH Amsterdam The Netherlands 1. Registration 2. Accommodations 3. Meeting Schedule 1. Registration A. Fee: $100 USD B. Register online at: http://www.ietf.org/registration/lim2012/ietfreg.py C. Online Registration and Payment closes on 28 September 2012 D. On Site Registration starting Saturday, 29 September at 8:00 AM 2. Accommodations A block of rooms is being held at the Hotel Okura Amsterdam (meeting venue= ) for the nights of September 28 and 29. Rate: 195 EUR [256 USD; 20,065 JPY] Rate includes breakfast and guest room wireless internet but excludes 5%= city tax. To make your reservation on line, please go to: www.okura.nl Group Code: IETF2012 Guest Cancellation: - Reservations may be changed up to 1 week prior to the event without pena= lty. (You can change, not cancel, the reservation, i.e. change arrival, departure dates or name, up to 1 week without penalty but not cancel the reservation without penalty.) - 50% of reservation value penalty for cancellation less than 14 days and = greater than 7 days prior to event. If you cancel, not change, the reservat= ion less than 14 days but more than 7 days prior to the event you will be c= harged 50% of the total reservation fee. - 80% of reservation value penalty for cancellation less than 7 days and g= reater than 3 days prior to event. If you cancel, not change, the reservati= on less than 7 days prior to the event you will be charged 80% of the total= reservation fee. - 100% of reservation value penalty for cancellation less than 3 days prio= r to event or non-arrival or no-show. - In case of early departure, the full value of the reservation will be ch= arged to the guest. If you have any problems making your reservation, please send a message to = agenda@ietf.org 3. Meeting Agenda 0800-1700 Okura Foyer Registration 0830-0900 Okura Foyer AM Coffee 0900-1130 Room: Otter SIDR 0900-1130 Room: Heian I OPSEC 1030-1100 Okura Foyer AM Break 1130-1330 On Own Lunch Break 1330-1700 Room: Otter SIDR 1330-1700 Room: Heian I V6OPS 1500-1530 Okura Foyer PM Break From david.freedman@uk.clara.net Thu Sep 27 05:29:25 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 D1EF121F85C7 for ; Thu, 27 Sep 2012 05:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6VwTXoHfpBN for ; Thu, 27 Sep 2012 05:29:25 -0700 (PDT) Received: from staff01.mail.eu.clara.net (staff01.mail.eu.clara.net [IPv6:2001:a88:0:fff7::54]) by ietfa.amsl.com (Postfix) with ESMTP id 53B6C21F85C3 for ; Thu, 27 Sep 2012 05:29:25 -0700 (PDT) Received: from [195.157.10.59] (port=30923 helo=SRVGREXCAS02.claranet.local) by staff01.mail.eu.clara.net (staff01.mail.eu.clara.net [80.168.65.54]:25) with esmtps (TLS-1.0:RSA_AES_128_CBC_SHA1:16) id 1THDDW-0005lp-5x for opsec@ietf.org (return-path ); Thu, 27 Sep 2012 12:29:22 +0000 Received: from SRVGREXMB02.claranet.local ([10.75.5.12]) by SRVGREXCAS02.claranet.local ([fe80::cd6a:3120:3174:a299%10]) with mapi id 14.02.0318.001; Thu, 27 Sep 2012 13:29:22 +0100 From: David Freedman To: "opsec@ietf.org" Thread-Topic: Comments on draft-jdurand-bgp-security-02 Thread-Index: AQHNnKu3WrxGACmI90KZhJSLw3Z/1w== Date: Thu, 27 Sep 2012 12:29:21 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [172.18.6.3] Content-Type: text/plain; charset="us-ascii" Content-ID: <73D6EBE9116C064F917F809C2F867D22@claranet.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BorderScout-Spam: 0.00 X-BorderScout-Virus: clean Subject: [OPSEC] Comments on draft-jdurand-bgp-security-02 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, 27 Sep 2012 12:29:25 -0000 Sec 9. Next-Hop Filtering >In direct peerings between ISPs, this is undesirable, >peers could trick the other one to send packets into >a black hole Trick? I think I would want to do this in particular circumstances, when there is a DoS ongoing. (yes, I'm aware there are community approaches, these aren't widely adopted, this technique works for many networks now and is quite invaluable to preserve). What I wouldn't want however is for a peer to set a next-hop as something internal to my network (I.e an internal endpoint) which could enable them to manipulate internal traffic (say, to steal a service by causing me to route it internally). >Therefore, the authors recommend to, by default, apply an inbound >route policy to IXP peerings which sets the next-hop for accepted >prefixes to the BGP peer that sent the prefix (which is what "next- >hop-self" would enforce on the sending side, but you can not rely on >the other party to always send correct information). I'm not aware of any implementations which can achieve this in a scalable way, are the authors? at present I would have to statically configure a next hop for each peer, not fun. Also, are you aware that some networks inject the IXP LAN into their IGP for the purposes of TE? (I.e leaving the IXP LAN next hop present in their iBGP and then doing MPLS TE on this LAN as opposed to next-hop-self on the border where all peering networks are collapsed into a single loopback) Dave. From gert@space.net Thu Sep 27 05:56: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 04C9521F8504 for ; Thu, 27 Sep 2012 05:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cvcy9xNBinEZ for ; Thu, 27 Sep 2012 05:56:13 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4702B21F84FA for ; Thu, 27 Sep 2012 05:56:12 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 2429BF8CB6 for ; Thu, 27 Sep 2012 14:56:11 +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 08750F8C7E for ; Thu, 27 Sep 2012 14:56:11 +0200 (CEST) Received: (qmail 82155 invoked by uid 1007); 27 Sep 2012 14:56:10 +0200 Date: Thu, 27 Sep 2012 14:56:10 +0200 From: Gert Doering To: David Freedman Message-ID: <20120927125610.GC13776@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Comments on draft-jdurand-bgp-security-02 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, 27 Sep 2012 12:56:14 -0000 Hi, On Thu, Sep 27, 2012 at 12:29:21PM +0000, David Freedman wrote: > I'm not aware of any implementations which can achieve > this in a scalable way, are the authors? at present I > would have to statically configure a next hop for each peer, > not fun. Both Cisco and Juniper can do route-map foo permit 10 set ip(v6) next-hop peer-address (dunno the exact Juniper syntax, but have been told it can be done) DFN(680) stated on the DECIX list that the have been doing this on Cisco "since ever" and it works. > Also, are you aware that some networks inject the IXP > LAN into their IGP for the purposes of TE? (I.e leaving > the IXP LAN next hop present in their iBGP and then > doing MPLS TE on this LAN as opposed to next-hop-self > on the border where all peering networks are collapsed > into a single loopback) Yeah, I did. At some point. Maybe we need to add a bit more language to the point of "if you need to deviate from these recommendations, understand why you are doing this, and then feel free to do so" (= "SHOULD" normative language). Gert Doering -- NetMaster -- 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 kkumar@google.com Thu Sep 27 15:06: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 8D61821F8496 for ; Thu, 27 Sep 2012 15:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.791 X-Spam-Level: X-Spam-Status: No, score=-102.791 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ix4VWIeFWYrS for ; Thu, 27 Sep 2012 15:06:13 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABC221F8435 for ; Thu, 27 Sep 2012 15:06:13 -0700 (PDT) Received: by qabj40 with SMTP id j40so2562221qab.10 for ; Thu, 27 Sep 2012 15:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=iOpPKm808szDWC6KXnCab/y3zDUPpOHw6hIar1qez4Y=; b=E9u2m3+g7J0g7f2AA8pDOzr0DVPy86gON3YkH+F+Qz5TEp0cpCGX1TrpOqjmZlUfxB 2uNQxEBla6jm5ahaKfOCMqtr+M/pghZioWdy+jXT9Uca3t4LHr+Qxy7M6PDtRwDurood +IL+oN+9Wakq+jdUUJuJxJV3ZKyodM7r1zhWF9mt4UupnjnwElGgYhQ4mhJIKTFNGGm7 HYq2Ktu36vBKkpBi1h1yFPLdSutcu9lhLBvj6Z0E/uM5RCXP4vMANgBq8gW9MIzglT9j +0b0P+vMMpK1tF1YABo3aArXMamgBFJlRKhbd1Zgm5h3GtcqlipxCS1oYJqH3kBaWV/K Z+KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=iOpPKm808szDWC6KXnCab/y3zDUPpOHw6hIar1qez4Y=; b=S4rNHGqnDdD4jtAKqn5CnvsYj/Kz0ZVFJuI3tss95fYeOnHGlzDUEmwkoZlodj4fKw IlfQLubx8blAl62iV7qIZiCgqibV3ij5eyZY1j0QyhiWm10QIa64Wzjtm5G4BTk/i8SE UckVANyo0MyyWUlL7K7zTp0XWHO+AE8DOUOKxjp9QuWkjQ5Ng+kYbLftuh+r5i9hpvSE EiakqS+q+8jOE5GDyCR7h5+ye4vpsMAbrG7uHPU196QIdTe/QKoo6Bt6aM7G3IlEWU/n /5U5uKknc0662Vg7029wXHbGCv3h3MNYoIi6o12CFSmo21aXVMX/E2Rq8ar9a17wqMu6 3YtA== Received: by 10.224.220.84 with SMTP id hx20mr12838926qab.5.1348783572922; Thu, 27 Sep 2012 15:06:12 -0700 (PDT) Received: by 10.224.220.84 with SMTP id hx20mr12838907qab.5.1348783572730; Thu, 27 Sep 2012 15:06:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.94.114 with HTTP; Thu, 27 Sep 2012 15:05:52 -0700 (PDT) From: KK Date: Thu, 27 Sep 2012 15:05:52 -0700 Message-ID: To: opsec@ietf.org Content-Type: multipart/alternative; boundary=20cf3074b2a0bb417f04cab6257b X-System-Of-Record: true X-Gm-Message-State: ALoCoQl4GFYSCmcG6lAqyQEko50GpDHbhoMREcyZALdE/h7LjhrUf0pAjQGLg+d7US+MK59eJSjL5dxK8O6gSKstpa8m3Legt4DvlseCOiNL3Wn8SODf+JZFzJuhZlcYuXJUfipZXSFUicY/lanjjTrpFcQdUIn8RdA8Uk8/2Es9mWYxAkGAd4fKRed6v3fHKn0AjgAL/cPA Subject: [OPSEC] Remote Participation at IETF interim 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, 27 Sep 2012 22:06:14 -0000 --20cf3074b2a0bb417f04cab6257b Content-Type: text/plain; charset=ISO-8859-1 Hey Folks, Just wanted to let you know that remote participation will be enabled by meetecho. Further details at:http://ietf-lim.conf.meetecho.com/ For folks who will be physically attending, we will be meeting in room 'Heian' at the Okura. An updated agenda has been posted here: http://www.ietf.org/proceedings/interim/2012/09/29/opsec/agenda/agenda-interim-2012-opsec-1 Regards, KK, Gunter, Warren --20cf3074b2a0bb417f04cab6257b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Folks,

Just wanted to let you know that remote parti= cipation will be enabled by meetecho. Further details at:http://ietf-lim.conf.meetecho.com/

For folks who will be physically attending, we will be meeti= ng in room 'Heian' at the Okura.


Regards,
KK, Gunter, Warren
--20cf3074b2a0bb417f04cab6257b-- From evyncke@cisco.com Fri Sep 28 04:59: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 B327821F85EF; Fri, 28 Sep 2012 04:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4tXsN4ODdQgL; Fri, 28 Sep 2012 04:59:17 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6691121F84EA; Fri, 28 Sep 2012 04:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3291; q=dns/txt; s=iport; t=1348833557; x=1350043157; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=k8zPZFA7G99PmhW631upai5SKi7Lf/BeFjiqFV9Oa+4=; b=WIo2F57sH9ClwZy+PiH0dHclLwMx6rd3xtf1MgOi6009Je9fe9zabzLZ 8SoDx+kxXVvm80l8h54BrowHV7vqDNbfbu0wJ41pjc63/z+oiUcPg4DPW oQ0iKv1Wrznzz/ZLwvHx0gGU00uAMt4Wb7oA72bw031qI76WvIZLQthi8 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD+QZVCtJXG9/2dsb2JhbABFvg6BCIIgAQEBBAEBAQ8BNiUXBAIBCBEEAQELHQcnCxQJCAIEARIIARmHYwuXbqAqixiFR2ADiCOcCIFpgmeBWgQ5 X-IronPort-AV: E=Sophos;i="4.80,502,1344211200"; d="scan'208,223";a="126330244" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 28 Sep 2012 11:59:17 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q8SBxGAo002588 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Sep 2012 11:59:16 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.26]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Fri, 28 Sep 2012 06:59:16 -0500 From: "Eric Vyncke (evyncke)" To: IETF Secretariat , "opsec@ietf.org" , "v6ops@ietf.org" Thread-Topic: [OPSEC] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS Thread-Index: AQHNm/ic4ZMPgDd4lECEBlqdIyqPGJefqIHw Date: Fri, 28 Sep 2012 11:59:15 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E11183738F@xmb-aln-x02.cisco.com> References: <20120926150705.8596.75260.idtracker@ietfa.amsl.com> In-Reply-To: <20120926150705.8596.75260.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.90.219] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19216.004 x-tm-as-result: No--48.802400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS 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: Fri, 28 Sep 2012 11:59:18 -0000 >From what I gathered, the agenda for OPSEC and V6OPS will be shorter than t= heir allocated length. If this is the case, then may I suggest to group OPSEC & V6OPS on the Satur= day morning slot? This would probably allow several people to return home e= arlier (especially after 5 days of RIPE) and would also allow for a more ef= ficient use of our time. Just my 0,01 EUR -=E9ric > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of > IETF Secretariat > Sent: mercredi 26 septembre 2012 17:07 > To: opsec@ietf.org; v6ops@ietf.org; sidr@ietf.org > Subject: [OPSEC] IETF Large Interim Meeting - OPSEC, SIDR and V6OPS >=20 > OPSEC, SIDR and V6OPS Interim Meeting > Amsterdam, The Netherlands > 29 September 2012 > Venue: Hotel Okura Amsterdam (www.okura.nl) > Ferdinand Bolstraat 333 > 1072 LH Amsterdam > The Netherlands >=20 > 1. Registration > 2. Accommodations > 3. Meeting Schedule >=20 > 1. Registration > A. Fee: $100 USD > B. Register online at: http://www.ietf.org/registration/lim2012/ietfreg= .py > C. Online Registration and Payment closes on 28 September 2012 D. On = Site > Registration starting Saturday, 29 September at 8:00 AM >=20 > 2. Accommodations > A block of rooms is being held at the Hotel Okura Amsterdam (meeting ven= ue) > for the nights of September 28 and 29. > Rate: 195 EUR [256 USD; 20,065 JPY] > Rate includes breakfast and guest room wireless internet but excludes = 5% > city tax. > To make your reservation on line, please go to: www.okura.nl > Group Code: IETF2012 >=20 > Guest Cancellation: > - Reservations may be changed up to 1 week prior to the event without > penalty. (You can change, not cancel, the reservation, i.e. change arriva= l, > departure dates or name, up to 1 week without penalty but not cancel the > reservation without penalty.) > - 50% of reservation value penalty for cancellation less than 14 days an= d > greater than 7 days prior to event. If you cancel, not change, the > reservation less than 14 days but more than 7 days prior to the event you > will be charged 50% of the total reservation fee. > - 80% of reservation value penalty for cancellation less than 7 days and > greater than 3 days prior to event. If you cancel, not change, the > reservation less than 7 days prior to the event you will be charged 80% o= f > the total reservation fee. > - 100% of reservation value penalty for cancellation less than 3 days pr= ior > to event or non-arrival or no-show. > - In case of early departure, the full value of the reservation will be > charged to the guest. >=20 > If you have any problems making your reservation, please send a message t= o > agenda@ietf.org >=20 > 3. Meeting Agenda > 0800-1700 Okura Foyer Registration > 0830-0900 Okura Foyer AM Coffee > 0900-1130 Room: Otter SIDR > 0900-1130 Room: Heian I OPSEC > 1030-1100 Okura Foyer AM Break >=20 > 1130-1330 On Own Lunch Break >=20 > 1330-1700 Room: Otter SIDR > 1330-1700 Room: Heian I V6OPS > 1500-1530 Okura Foyer PM Break > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From fred@cisco.com Sat Sep 29 00:25:53 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 57A3521F83EF; Sat, 29 Sep 2012 00:25:53 -0700 (PDT) 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, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2-vvWc2CYKM; Sat, 29 Sep 2012 00:25:51 -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 5F50721F8504; Sat, 29 Sep 2012 00:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=284; q=dns/txt; s=iport; t=1348903549; x=1350113149; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=WKxCZMC5jufLFOtm0SggHZzxKT9oDNlFtvuXxatwRho=; b=W0ZyOuq/V4Y4yHM2aKyiHjsM/RQugzrkeC/oSQQv4w9jh2L7Wgb1yfCe WcWDEiMSRI17Fs1HhBDtGwBIUvyICI29qXd2kETxpg2wD2zkH44Xo9elX Ml3nr9zzcSsWd1bdEKH3c9tmG71DDTjvf6S21Zojlj8opAj8Hs/tw9V5c A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFAEigZlCtJXG8/2dsb2JhbABFhUS4bYEIgicSASc/EgE+QicEDieHYwuZEaALkQpgA5VpgRWNLYFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,506,1344211200"; d="scan'208";a="126633503" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 29 Sep 2012 07:25:48 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8T7PmKG026546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 29 Sep 2012 07:25:48 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.97]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Sat, 29 Sep 2012 02:25:48 -0500 From: "Fred Baker (fred)" To: IPv6 Ops WG Thread-Topic: Review requested, especially from operators Thread-Index: AQHNnhOlCheRYAsFwEyGJ5OK73TSGw== Date: Sat, 29 Sep 2012 07:25:47 +0000 Message-ID: <9995D494-0818-461B-BBC0-53A1974BCA94@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.251.134] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19220.001 x-tm-as-result: No--25.051600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <9AEE9463227A9F4CADFCE34AF71B618B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "opsec@ietf.org" Subject: [OPSEC] Review requested, especially from operators 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, 29 Sep 2012 07:25:53 -0000 The authors of http://tools.ietf.org/html/draft-ietf-opsec-v6 "Operational Security Considerations for IPv6 Networks", KK Chittimaneni, Merike Kaeo, Eric Vyncke, 21-Sep-12 are requesting operational review of the document and specific comments. Pl= ease post to opsec.= From fred@cisco.com Sat Sep 29 04:24:03 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 676D221F84EF for ; Sat, 29 Sep 2012 04:24:03 -0700 (PDT) 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, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6qR2Kq8bBp4c for ; Sat, 29 Sep 2012 04:24:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BCA0921F84D1 for ; Sat, 29 Sep 2012 04:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=864; q=dns/txt; s=iport; t=1348917842; x=1350127442; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=PaIvZOXFMGZIy7+iAJzSEjZhDabOK+hsjqokDwiAKmI=; b=c0nvN+pd/UcCuHIyhdfQFt4P3+nXe/WatozfPmSydcceqie5IJJroKqa bcTJGuArQahHVA6jUHZWYtyhs9P3wQbQVGfpmXKSTKwLt62V+c9j+DhCt GWzaFX1xIzSRYEqPg1eHFmUFGmX4oZNKi1SKdQV5IF9q6O19jKBlqDzql M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4FAIjZZlCtJXHB/2dsb2JhbABFhUS4bYEIgiABAQEDARIBJ0QLAgEZAwECHxAyGwIIAgQTIoddBplkn3iLH4VrYAOVaY5CgWmCZ4IX X-IronPort-AV: E=Sophos;i="4.80,507,1344211200"; d="scan'208";a="126634763" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 29 Sep 2012 11:24:02 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q8TBO2jM023778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 29 Sep 2012 11:24:02 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.26]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Sat, 29 Sep 2012 06:24:01 -0500 From: "Fred Baker (fred)" To: "opsec@ietf.org" Thread-Topic: [v6ops] Review requested, especially from operators Thread-Index: AQHNni29X6xOC4LPnkGhi97KWJsChg== Date: Sat, 29 Sep 2012 11:24:01 +0000 Message-ID: References: <5066CE05.4070501@lanparty.ee> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.222.29] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19220.001 x-tm-as-result: No--40.041100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <69E08CCA96959F42A75BEBCA464BFA81@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSEC] Fwd: [v6ops] Review requested, especially from operators 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, 29 Sep 2012 11:24:03 -0000 Begin forwarded message: > From: Tarko Tikan > Subject: Re: [v6ops] Review requested, especially from operators > Date: September 29, 2012 12:31:33 PM GMT+02:00 > To: "Fred Baker (fred)" >=20 > hey, >=20 > 2.3.2 mentions IPfix as management protocol but IPfix is push only and is= not affected by ingress management ACL. >=20 > 2.5 IPfix is incorrectly linked to RFC2740 (OSPFv6) >=20 > Coming from someone who is working with IP/MPLS on daily basis, I'd add a= little warning to 2.6.1. Dual-stack is indeed easy to turn on but if you r= un MPLS and expect your IPv6 traffic to be labelled same way your IPv4 is (= BGP-free core, MPLS EXP based QOS, etc.), this is not going to happen and o= ne should look into 6PE instead. >=20 > Other than that, nice summary. >=20 > --=20 > tarko >=20 >=20 From ietf@meetecho.com Sat Sep 29 06:28:29 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 B7AB721F84C9 for ; Sat, 29 Sep 2012 06:28:29 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doc5OWjsML8M for ; Sat, 29 Sep 2012 06:28:27 -0700 (PDT) Received: from smtplq03.aruba.it (smtplq-out13.aruba.it [62.149.158.33]) by ietfa.amsl.com (Postfix) with SMTP id 341FA21F8484 for ; Sat, 29 Sep 2012 06:28:26 -0700 (PDT) Received: (qmail 2399 invoked by uid 89); 29 Sep 2012 13:28:23 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq03.aruba.it with SMTP; 29 Sep 2012 13:28:23 -0000 Received: (qmail 23859 invoked by uid 89); 29 Sep 2012 13:28:23 -0000 Received: from unknown (HELO ?10.116.0.195?) (alex@meetecho.com@62.50.252.111) by smtp2.ad.aruba.it with ESMTPA; 29 Sep 2012 13:28:23 -0000 Message-ID: <5066F76C.8010803@meetecho.com> Date: Sat, 29 Sep 2012 15:28:12 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 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: smtplq03.aruba.it 1.6.2 0/1000/N Subject: [OPSEC] Meetecho session recording available 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, 29 Sep 2012 13:28:29 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of the OPSEC session at IETF interim in Amsterdam is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf-interim/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From fred@cisco.com Sat Sep 29 06:29:43 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 1D41D21F84D8 for ; Sat, 29 Sep 2012 06:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOc5Mce63VH7 for ; Sat, 29 Sep 2012 06:29:40 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4393D21F85F0 for ; Sat, 29 Sep 2012 06:29:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1712; q=dns/txt; s=iport; t=1348925380; x=1350134980; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=3kVKUSJMArl1JmH1qICRP5lnD3uWqjVRyDeYmZ+P/fU=; b=nD+lO5VQgfz6+nNz0/AdCzViIdKc57ez3519XZFLu/cDQ48OjzPpzVkM T/WuRwQLbnLBXa3Bv4R76rY8yoLYtsFYR120jKBGDhi+Qb/vbZbKeRkVu VkBBhCZek2hSQolmzXyPk8HfjZQaftvHXp9die7dXtFNAe/BsreEksSZw U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHv3ZlCtJXHA/2dsb2JhbABFvjGBCIIgAQEBAwEBAQEPASc0EAsCARkDAQIfECcLGwIIAgQTIoddBguaAJ9tix+Fa2ADlWmBFY0tgWmCZ4IX X-IronPort-AV: E=Sophos;i="4.80,507,1344211200"; d="scan'208";a="126669332" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 29 Sep 2012 13:29:39 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q8TDTdwI007184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 29 Sep 2012 13:29:39 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.26]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Sat, 29 Sep 2012 08:29:39 -0500 From: "Fred Baker (fred)" To: "opsec@ietf.org" Thread-Topic: [OPSEC] [v6ops] Review requested, especially from operators Thread-Index: AQHNni29X6xOC4LPnkGhi97KWJsChg== Date: Sat, 29 Sep 2012 13:29:38 +0000 Message-ID: <5C978B65-FCAC-406E-976C-80A74ECF11ED@cisco.com> References: <5066CE05.4070501@lanparty.ee> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.222.29] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19220.001 x-tm-as-result: No--43.647700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <5F8F53F8D9184C428BA987DDA599CD87@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [OPSEC] Fwd: [v6ops] Review requested, especially from operators 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, 29 Sep 2012 13:29:43 -0000 I should have said that this is a private response to >=20 > From: "Fred Baker (fred)" > Subject: [v6ops] Review requested, especially from operators > Date: September 29, 2012 9:25:47 AM GMT+02:00 > To: IPv6 Ops WG > Cc: "opsec@ietf.org" >=20 > The authors of >=20 > http://tools.ietf.org/html/draft-ietf-opsec-v6 > "Operational Security Considerations for IPv6 Networks", KK > Chittimaneni, Merike Kaeo, Eric Vyncke, 21-Sep-12 >=20 > are requesting operational review of the document and specific comments. = Please post to opsec. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From: Tarko Tikan > Subject: Re: [v6ops] Review requested, especially from operators > Date: September 29, 2012 12:31:33 PM GMT+02:00 > To: "Fred Baker (fred)" >=20 > hey, >=20 > 2.3.2 mentions IPfix as management protocol but IPfix is push only and is= not affected by ingress management ACL. >=20 > 2.5 IPfix is incorrectly linked to RFC2740 (OSPFv6) >=20 > Coming from someone who is working with IP/MPLS on daily basis, I'd add a= little warning to 2.6.1. Dual-stack is indeed easy to turn on but if you r= un MPLS and expect your IPv6 traffic to be labelled same way your IPv4 is (= BGP-free core, MPLS EXP based QOS, etc.), this is not going to happen and o= ne should look into 6PE instead. >=20 > Other than that, nice summary. >=20 > --=20 > tarko >=20 >=20 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From ietf@meetecho.com Sat Sep 29 06:45:16 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 19A3721F8532 for ; Sat, 29 Sep 2012 06:45:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEqPgshfydwJ for ; Sat, 29 Sep 2012 06:45:15 -0700 (PDT) Received: from smtplq01.aruba.it (smtplq-out13.aruba.it [62.149.158.33]) by ietfa.amsl.com (Postfix) with SMTP id 0ADBB21F852E for ; Sat, 29 Sep 2012 06:45:14 -0700 (PDT) Received: (qmail 26215 invoked by uid 89); 29 Sep 2012 13:45:12 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq01.aruba.it with SMTP; 29 Sep 2012 13:45:12 -0000 Received: (qmail 23737 invoked by uid 89); 29 Sep 2012 13:45:12 -0000 Received: from unknown (HELO ?10.116.0.195?) (alex@meetecho.com@62.50.252.111) by smtp2.ad.aruba.it with ESMTPA; 29 Sep 2012 13:45:12 -0000 Message-ID: <5066FB5D.5090603@meetecho.com> Date: Sat, 29 Sep 2012 15:45:01 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 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: smtplq01.aruba.it 1.6.2 0/1000/N Subject: [OPSEC] Meetecho session recording available 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, 29 Sep 2012 13:45:16 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of the OPSEC session at IETF interim in Amsterdam is available. You can watch it by accessing the following URL: http://www.meetecho.com/ietf-interim/recordings For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to team@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From ipepelnjak@gmail.com Sat Sep 29 07:22:09 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 D694121F851B for ; Sat, 29 Sep 2012 07:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI0+ChfnJATb for ; Sat, 29 Sep 2012 07:22:09 -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 005C721F84EE for ; Sat, 29 Sep 2012 07:22:08 -0700 (PDT) Received: by weyu46 with SMTP id u46so2216622wey.31 for ; Sat, 29 Sep 2012 07:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=IzXGYhqeZj6l68Oqr1Ir8zr0wP57NBqoQyDSzyh6R88=; b=aBlg/poQYNttSGg5xd7fVtS/Lix+PlRr05yY+FooHrLssanylJQFww42pb6TsHxlzr XD8u390yqMPNJKua9qM99yfKpyF7CeWiu1XzyOV8LaVerK+z5B7A5efvzU4AC7Aw/W1s 3/tWIvW6OhTJyEeiHYLBm8BZVKOqK06Ef9z40gTCUqSY8pImdf0XAShS/GaIelk7GasZ qgaHiFfzODFTUPWDoDbJmzbearN2moN2CR5b+loRIe9dbaJPSHsTMGCNpl/ryUEwt0Ki nqF22YpNnuxv7eXlR8FJpdG2lPj6UuTSWD8J71L1mJK/WYCJk2mT7SbPLKkEBcfOH4Vh sXSQ== Received: by 10.180.108.45 with SMTP id hh13mr3919997wib.15.1348928528103; Sat, 29 Sep 2012 07:22:08 -0700 (PDT) Received: from PIPINB2009 (BSN-61-57-40.dial-up.dsl.siol.net. [86.61.57.40]) by mx.google.com with ESMTPS id dm3sm6025596wib.3.2012.09.29.07.22.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 29 Sep 2012 07:22:06 -0700 (PDT) From: "Ivan Pepelnjak" To: "'Gert Doering'" , "'David Freedman'" References: <20120927125610.GC13776@Space.Net> In-Reply-To: <20120927125610.GC13776@Space.Net> Date: Sat, 29 Sep 2012 16:22:04 +0200 Message-ID: <000e01cd9e4d$cdb1e2b0$6915a810$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2cr3wquAbIaod4Tm2rYJN36hUG8gBnRPIQ Content-Language: sl Cc: opsec@ietf.org Subject: Re: [OPSEC] Comments on draft-jdurand-bgp-security-02 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, 29 Sep 2012 14:22:10 -0000 David, On the IXP LAN prefix front, there's nothing in the draft saying you = shouldn't propagate it (maybe even in deaggregated form) in your IGP. = What it says is (or maybe I'm just reading it wrong): * You MUST NOT accept more specific prefixes (for obvious reasons); * If you do accept it, take care that the EBGP route doesn't become = better than an IGP route (leading to recursive routing problems) or use = next-hop-self; * It MUST only be accepted from ASes authorized to announce it (OK, this = one MAY use a rewording). * Exact IXP LAN prefix (accepted from proper AS) SHOULD be propagated to = downstreams for uRPF checks on pMTUd ICMP replies. On the next-hop filtering (section 9), I agree we MUST mention use of = EBGP next hops for RTBH, including a reference to RFC 6666. Thanks again for the comments, Ivan > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf = Of > Gert Doering > Sent: Thursday, September 27, 2012 2:56 PM > To: David Freedman > Cc: opsec@ietf.org > Subject: Re: [OPSEC] Comments on draft-jdurand-bgp-security-02 >=20 > Hi, >=20 > On Thu, Sep 27, 2012 at 12:29:21PM +0000, David Freedman wrote: > > I'm not aware of any implementations which can achieve this in a > > scalable way, are the authors? at present I would have to statically > > configure a next hop for each peer, not fun. >=20 > Both Cisco and Juniper can do >=20 > route-map foo permit 10 > set ip(v6) next-hop peer-address >=20 > (dunno the exact Juniper syntax, but have been told it can be done) >=20 > DFN(680) stated on the DECIX list that the have been doing this on = Cisco > "since ever" and it works. >=20 > > Also, are you aware that some networks inject the IXP LAN into their > > IGP for the purposes of TE? (I.e leaving the IXP LAN next hop = present > > in their iBGP and then doing MPLS TE on this LAN as opposed to > > next-hop-self on the border where all peering networks are collapsed > > into a single loopback) >=20 > Yeah, I did. At some point. >=20 > Maybe we need to add a bit more language to the point of "if you need = to > deviate from these recommendations, understand why you are doing this, = and > then feel free to do so" (=3D "SHOULD" normative language). >=20 > Gert Doering > -- NetMaster > -- > have you enabled IPv6 on something today...? >=20 > 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 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From jouni.nospam@gmail.com Sun Sep 30 03:23:25 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 9EF9621F856C for ; Sun, 30 Sep 2012 03:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b96nzRXxLOmV for ; Sun, 30 Sep 2012 03:23:25 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7BF721F850B for ; Sun, 30 Sep 2012 03:23:24 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2098224wgb.13 for ; Sun, 30 Sep 2012 03:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=EVgLpwzKQ5IjoCeuQBmGcGfqq//UC6kf+DtuamtKsms=; b=1AzlSKhPe5tdwFmOeHXKu1afqzINsMe/rJCtCzRnWASkPiguui8l+eFybQzp7uz5Pr HJcM3XNRf7wDdeMPXhtiNm//G19owXPEoyguL/iXlWW5dVVuT38/y2anrkKUhYf7KTqj /jhkm95lwbJEQ7QQOr12kNpkUUTDB3/40vQ0MB2i8a0zqZulZASgfMAtGrpqEOBmpdIe T16vQMgibj41iey1ZKdmegbTmTMCKgZJXotHk7AGtjyfKq2hlhxER+AKzmjEU9wMbsst tdXxPf7peerss5ZAUWq3k8cON1363EAtlImoZkDRmXV4dl2AfduE6Y8qfqblSPrElT0y 2Sog== Received: by 10.216.123.130 with SMTP id v2mr6214467weh.117.1349000603730; Sun, 30 Sep 2012 03:23:23 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id l6sm10015858wiz.4.2012.09.30.03.23.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 30 Sep 2012 03:23:22 -0700 (PDT) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 30 Sep 2012 13:23:20 +0300 Message-Id: <7261E144-2FED-4725-A723-65F24FA1FEE4@gmail.com> To: opsec@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [OPSEC] comments on opsec-v6-00 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, 30 Sep 2012 10:23:25 -0000 I already sent few comments offline to the authors but for the sake of openness here they are again on the list. The first set concerns Section 2.6.3.2. NAT64/DNS64. o I would suggest a reference to Section 3.1 of draft-ietf-behave-nat64-discovery-heuristic into the second paragraph that mentions DNSSEC. The BEHAVE draft has a nice text of using DNSSEC to validate the discovered the Pref64::/n. o I don't think the statement that UDP encapsulated IPsec would survive NAT64 is correct as a blank statement. I have hard time seeing how IKE or SPDs would work. Or is the assumption that IPsec is manually configured on the "IPv4-only host", which is then actually a dual stack host but with IPv4 only interface terminating IPsec? If so that should be pointed out. - Jouni