From nobody Sun Mar 2 03:35:30 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7111A0D61 for ; Sun, 2 Mar 2014 03:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l92XHW5guC_8 for ; Sun, 2 Mar 2014 03:35:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id 677B91A0D6E for ; Sun, 2 Mar 2014 03:35:23 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id EBEC87FC39B; Sun, 2 Mar 2014 03:35:20 -0800 (PST) To: dave@juniper.net, cpignata@cisco.com, rodunn@cisco.com, bclaise@cisco.com, joelja@bogus.com, kk@google.com, gvandeve@cisco.com From: RFC Errata System Message-Id: <20140302113520.EBEC87FC39B@rfc-editor.org> Date: Sun, 2 Mar 2014 03:35:20 -0800 (PST) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/VEMszJvU7_YPPdS8tACU4WMa6CI Cc: opsec@ietf.org, rfc-editor@rfc-editor.org, nick@foobar.org Subject: [OPSEC] [Technical Errata Reported] RFC6192 (3906) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 11:35:26 -0000 The following errata report has been submitted for RFC6192, "Protecting the Router Control Plane". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6192&eid=3906 -------------------------------------- Type: Technical Reported by: Nick Hilliard Section: A.1 Original Text ------------- [...] ip access-list extended DNS permit udp 198.51.100.0 0.0.0.252 eq domain any ipv6 access-list DNSv6 permit udp 2001:DB8:100:1::/64 eq domain any permit tcp 2001:DB8:100:1::/64 eq domain any ip access-list extended NTP permit udp 198.51.100.4 255.255.255.252 any eq ntp ipv6 access-list NTPv6 permit udp 2001:DB8:100:2::/64 any eq ntp ip access-list extended SSH permit tcp 198.51.100.128 0.0.0.128 any eq 22 ipv6 access-list SSHv6 permit tcp 2001:DB8:100:3::/64 any eq 22 ip access-list extended SNMP permit udp 198.51.100.128 0.0.0.128 any eq snmp [...] Corrected Text -------------- [...] ip access-list extended DNS permit udp 198.51.100.0 0.0.0.3 eq domain any ipv6 access-list DNSv6 permit udp 2001:DB8:100:1::/64 eq domain any permit tcp 2001:DB8:100:1::/64 eq domain any ip access-list extended NTP permit udp 198.51.100.4 0.0.0.3 any eq ntp ipv6 access-list NTPv6 permit udp 2001:DB8:100:2::/64 any eq ntp ip access-list extended SSH permit tcp 198.51.100.128 0.0.0.127 any eq 22 ipv6 access-list SSHv6 permit tcp 2001:DB8:100:3::/64 any eq 22 ip access-list extended SNMP permit udp 198.51.100.128 0.0.0.127 any eq snmp [...] Notes ----- The bitfield masks in the Cisco Configuration example in section A.1 look incorrect. The authors may have intended the following meanings: ip access-list extended DNS all hosts between 198.51.100.0 and 198.51.100.3 instead of all addresses in the range 198.51.100.0/24 which are evenly divisible by 4 ip access-list extended NTP all hosts between 198.51.100.4 and 198.51.100.7 instead of all addresses in the range 0.0.0.0/0 which are evenly divisible by 4 ip access-list extended SSH all hosts between 198.51.100.128 and 198.51.100.255 instead of 198.51.100.128/32 ip access-list extended SNMP all hosts between 198.51.100.128 and 198.51.100.255 instead of 198.51.100.128/32 Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6192 (draft-ietf-opsec-protect-control-plane-06) -------------------------------------- Title : Protecting the Router Control Plane Publication Date : March 2011 Author(s) : D. Dugal, C. Pignataro, R. Dunn Category : INFORMATIONAL Source : Operational Security Capabilities for IP Network Infrastructure Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Mar 3 09:03:14 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1147A1A027E for ; Mon, 3 Mar 2014 09:03:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91klbz8GQ7G8 for ; Mon, 3 Mar 2014 09:03:09 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BCBB71A0259 for ; Mon, 3 Mar 2014 09:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4618; q=dns/txt; s=iport; t=1393866186; x=1395075786; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MXjQRSBtKe1CLmnclrY7lKKp/lcpm8oEgapzELBzqYk=; b=iuBHln3drmBSQAwRPSMxu7D1CySK1M5KOWNIQysKTNHF+85kaNYAnkXU XRozGBxojdKxY91yYDySftS1+bCR/KfQ0DU834y9wUYRNYZiBH/gt4iRE 5ZT8wxnyvveZoHtzJwHubjU6M919DBkiutg9FRxh4szdsgdvXzaG2vn/D Q=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAKC0FFOtJV2a/2dsb2JhbABAGoMGO1fAUIEiFnSCJQEBAQMBeQULAgEIRjIlAgQOBQ6HYwgNNst0F45ZB4MkgRQEkEiBNIZAkiuDLXmBMQ X-IronPort-AV: E=Sophos;i="4.97,578,1389744000"; d="asc'?scan'208";a="307788684" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 03 Mar 2014 17:02:57 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s23H2vre004817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 17:02:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.205]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 11:02:56 -0600 From: "Carlos Pignataro (cpignata)" To: RFC Errata System Thread-Topic: [Technical Errata Reported] RFC6192 (3906) Thread-Index: AQHPNguA5hXB8Sz+yEO4I42pLv+4o5rP/VeA Date: Mon, 3 Mar 2014 17:02:56 +0000 Message-ID: <478FE875-1AAB-4A40-9635-F70D38E7E0B4@cisco.com> References: <20140302113520.EBEC87FC39B@rfc-editor.org> In-Reply-To: <20140302113520.EBEC87FC39B@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.80.107] Content-Type: multipart/signed; boundary="Apple-Mail=_BCC645E8-7505-4B98-8EEC-6F093E1A90FC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Ql4sijJ07osyx_B3EFK6fL_aUR0 Cc: "opsec@ietf.org" , "Rodney Dunn \(rodunn\)" , "nick@foobar.org" Subject: Re: [OPSEC] [Technical Errata Reported] RFC6192 (3906) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 17:03:12 -0000 --Apple-Mail=_BCC645E8-7505-4B98-8EEC-6F093E1A90FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Thank you for the report, Nick! You are correct in the four corrections = you reported, and the errata can be marked as Verified. Thanks, -- Carlos. On Mar 2, 2014, at 11:35 AM, RFC Errata System = wrote: > The following errata report has been submitted for RFC6192, > "Protecting the Router Control Plane". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6192&eid=3D3906 >=20 > -------------------------------------- > Type: Technical > Reported by: Nick Hilliard >=20 > Section: A.1 >=20 > Original Text > ------------- > [...] >=20 > ip access-list extended DNS >=20 > permit udp 198.51.100.0 0.0.0.252 eq domain any >=20 > ipv6 access-list DNSv6 >=20 > permit udp 2001:DB8:100:1::/64 eq domain any >=20 > permit tcp 2001:DB8:100:1::/64 eq domain any >=20 > ip access-list extended NTP >=20 > permit udp 198.51.100.4 255.255.255.252 any eq ntp >=20 > ipv6 access-list NTPv6 >=20 > permit udp 2001:DB8:100:2::/64 any eq ntp >=20 > ip access-list extended SSH >=20 > permit tcp 198.51.100.128 0.0.0.128 any eq 22 >=20 > ipv6 access-list SSHv6 >=20 > permit tcp 2001:DB8:100:3::/64 any eq 22 >=20 > ip access-list extended SNMP >=20 > permit udp 198.51.100.128 0.0.0.128 any eq snmp >=20 > [...] >=20 >=20 >=20 > Corrected Text > -------------- > [...] >=20 > ip access-list extended DNS >=20 > permit udp 198.51.100.0 0.0.0.3 eq domain any >=20 > ipv6 access-list DNSv6 >=20 > permit udp 2001:DB8:100:1::/64 eq domain any >=20 > permit tcp 2001:DB8:100:1::/64 eq domain any >=20 > ip access-list extended NTP >=20 > permit udp 198.51.100.4 0.0.0.3 any eq ntp >=20 > ipv6 access-list NTPv6 >=20 > permit udp 2001:DB8:100:2::/64 any eq ntp >=20 > ip access-list extended SSH >=20 > permit tcp 198.51.100.128 0.0.0.127 any eq 22 >=20 > ipv6 access-list SSHv6 >=20 > permit tcp 2001:DB8:100:3::/64 any eq 22 >=20 > ip access-list extended SNMP >=20 > permit udp 198.51.100.128 0.0.0.127 any eq snmp >=20 > [...] >=20 > Notes > ----- > The bitfield masks in the Cisco Configuration example in section A.1 = look incorrect. The authors may have intended the following meanings: >=20 >=20 >=20 > ip access-list extended DNS >=20 > all hosts between 198.51.100.0 and 198.51.100.3 instead of all = addresses in the range 198.51.100.0/24 which are evenly divisible by 4 >=20 >=20 >=20 > ip access-list extended NTP >=20 > all hosts between 198.51.100.4 and 198.51.100.7 instead of all = addresses in the range 0.0.0.0/0 which are evenly divisible by 4 >=20 >=20 >=20 > ip access-list extended SSH >=20 > all hosts between 198.51.100.128 and 198.51.100.255 instead of = 198.51.100.128/32 >=20 >=20 >=20 > ip access-list extended SNMP >=20 > all hosts between 198.51.100.128 and 198.51.100.255 instead of = 198.51.100.128/32 >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6192 (draft-ietf-opsec-protect-control-plane-06) > -------------------------------------- > Title : Protecting the Router Control Plane > Publication Date : March 2011 > Author(s) : D. Dugal, C. Pignataro, R. Dunn > Category : INFORMATIONAL > Source : Operational Security Capabilities for IP Network = Infrastructure > Area : Operations and Management > Stream : IETF > Verifying Party : IESG --Apple-Mail=_BCC645E8-7505-4B98-8EEC-6F093E1A90FC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlMUtcEACgkQtfDPGTp3USzgFQCcDNcgT7LlW4zT72Nc7BeK6ab1 oHQAn31ugoiclEAitlYJOWbJfyBEHZVk =Atkx -----END PGP SIGNATURE----- --Apple-Mail=_BCC645E8-7505-4B98-8EEC-6F093E1A90FC-- From nobody Mon Mar 3 11:29:12 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FC11A02AC; Mon, 3 Mar 2014 11:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id howcM_0bUetI; Mon, 3 Mar 2014 11:29:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2169A1A00AD; Mon, 3 Mar 2014 11:29:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303192906.20604.26214.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 11:29:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/q8_dcLV0F0Cmoki5kDOoEfOwy7U Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-vpn-leakages-04.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 19:29:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operational Security Capabilities for IP Network Infrastructure Working Group of the IETF. Title : Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks Author : Fernando Gont Filename : draft-ietf-opsec-vpn-leakages-04.txt Pages : 9 Date : 2014-03-03 Abstract: The subtle way in which the IPv6 and IPv4 protocols co-exist in typical networks, together with the lack of proper IPv6 support in popular Virtual Private Network (VPN) products, may inadvertently result in VPN traffic leaks. That is, traffic meant to be transferred over an encrypted and integrity protected VPN connection may leak out of such connection and be sent in the clear on the local network towards the final destination. This document discusses some scenarios in which such VPN leakages may occur as a result of employing IPv6-unaware VPN software. Additionally, this document offers possible mitigations for this issue. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-vpn-leakages-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-vpn-leakages-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 13 10:45:33 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28891A0A0F for ; Thu, 13 Mar 2014 10:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31aai4xBdAEG for ; Thu, 13 Mar 2014 10:45:28 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 182561A0492 for ; Thu, 13 Mar 2014 10:45:28 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id rd18so1356216iec.21 for ; Thu, 13 Mar 2014 10:45:21 -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; bh=gpVk2FJWOxINL36sj6M6kf3andwqS9h3gLj4OIozuEA=; b=j0QGIWDk5/4X7+oagZLiXrmU4L9uuybMxUyQ6nOjSg1qQ8gd4RA/xbVrYR+iqlGmty kJoZhcEY6EjMtm8poiGyBypgjisxokxBLNBPPh7GMT/bGr6txvePxiDV1QTcW1ggMTLq IlgSEXraqYjKZuxTbwSuGrFCzzEuudEzCHq8kDcoHmqnJXjJ3vPlyYaj5fZ0Q2xoYe1x Ug75oqZHdACcmJBGotOlwKiMyumxaMADkFcAignjrfPeV/oqihTUtD/3X/0EZe1niScY KgMzUsqgsBYuTtXFRPYI0FwopZQoW/PJGalEdl7ZBTGwSM3lZpcI3AJFjbhbSJwCcG6A kJKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=gpVk2FJWOxINL36sj6M6kf3andwqS9h3gLj4OIozuEA=; b=H7RGfmcjREQT1HeybPqxD8aY6TEhOfWPuBY8MBqFBcq3F7kBpi1wlFS5eZAdZSduIs WLhG0h9Gqc09KUYAZ4vuUZ4Gcpp6dX9G4ml4Q1BA4xjnf8UvODFGVEfDOPRsG19DbuaR hx8JST/RcCgM9Qi+gm1q9GWWYM2joz4+kbp1GhcllQ/CM+T+S3oekNBHIQgt7hv7weCN 58icA3p0s1GGxy+sc5YtRBa1ZJvuRF9gHHw7KpdsikuPsvjL9NaUQ5+j080Cf3pXKL/I QH/i77cAY5UC48qATFzegaIhrByiHjwLtIeF5L5QPqoTW3AvIIfUvjcgTiX4V675oAQj ZFfQ== X-Gm-Message-State: ALoCoQlJxc+vNb7m7ow7gKI2E4T9iivhnHYIpt8hVIDy91sFxP4skzt8TTx3nN65ir28t4z6ZJtQn/0z1UPU13QTjd87GUzj8M2jEItBs8pmbNWNQwhRXsDmispxNL/y7kKmkxUkchGftvL9XbdkkDXZn56MLnB2Bz1KYBtwm+gNo1xNu1JdlIH2uqX4iVCszFtkD+mOzD2s X-Received: by 10.43.145.137 with SMTP id ju9mr2723427icc.36.1394732721450; Thu, 13 Mar 2014 10:45:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.201.162 with HTTP; Thu, 13 Mar 2014 10:45:01 -0700 (PDT) From: KK Date: Thu, 13 Mar 2014 10:45:01 -0700 Message-ID: To: "opsec@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2e2b86b514004f48084fc Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/yahwjko0LUF1vr4nXOTpoIPWzJM Subject: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Mar 2014 17:45:30 -0000 --001a11c2e2b86b514004f48084fc Content-Type: text/plain; charset=UTF-8 Dear OpSec WG, Be not alarmed. This email was created to satisfy RFC 6702 "Promoting Compliance with Intellectual Property Rights (IPR)" (http://tools.ietf.org/rfc/rfc6702.txt ). The authors of draft-ietf-opsec-dhcpv6-shieldhave asked for a Working Group Last Call. Before issuing the Working Group Last Call, we would like to check whether any claims of Intellectual Property Rights (IPR) on the document have not yet been disclosed. Are you personally aware of any IPR that applies to draft-ietf-opsec-dhcpv6-shield? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please reply to this email regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor. If you are on the OpSec WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79. Please do not reply unless you want to make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at < http://www.ietf.org/ipr/file-disclosure>. Thanks, KK (as OpSec WG co-chair) --001a11c2e2b86b514004f48084fc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear OpSec WG,

Be not alarmed.
This email was = created to satisfy RFC 6702 "Promoting Compliance with Intellectual Pr= operty Rights (IPR)" =C2=A0(http://tools.ietf.org/rfc/rfc6702.txt).


The authors of draft-ietf-opsec-dhcpv6-shield h= ave asked for a Working Group Last Call. =C2=A0Before issuing the Working G= roup Last Call, we would like to check whether any claims of Intellectual P= roperty Rights (IPR) on the document have not yet been disclosed.

Are you personally aware of any IPR that applies to=C2=A0draft-ietf-opsec-dhcpv6-shield? =C2=A0If so, has this IPR = been disclosed in=C2=A0compliance with IETF IPR rules?

(See RFCs 3979, 4879, 3669, and 5378= for more details.)


If you are a document author or listed contributor on this docu= ment, please reply to this email regardless of whether or not you are perso= nally aware of any relevant IPR. =C2=A0We might not be able to advance this= document to the next stage until we have received a reply from each author= and listed contributor.


If you are on the OpSec WG email list but are not an author or = listed contributor for this document, you are reminded of your opportunity = for a voluntary IPR disclosure under BCP 79. =C2=A0Please do not reply unle= ss you want to make such a voluntary disclosure.


Online tools for filing IPR disclosures can be found at <<= span style=3D"vertical-align:baseline;background-color:transparent;font-fam= ily:Arial">http://www.ietf.org/ipr/file-disclosure&g= t;.


Thanks,

KK

(as OpSec WG co-chair)
--001a11c2e2b86b514004f48084fc-- From nobody Fri Mar 14 07:52:55 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1351A014F for ; Fri, 14 Mar 2014 07:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVCmoYHjzVCc for ; Fri, 14 Mar 2014 07:52:47 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE3B41A0154 for ; Fri, 14 Mar 2014 07:52:47 -0700 (PDT) Received: from 78-32-164-74.static.enta.net ([78.32.164.74] helo=[192.168.51.63]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WOTTS-000428-Bz; Fri, 14 Mar 2014 15:52:38 +0100 Message-ID: <532317A2.5040408@si6networks.com> Date: Fri, 14 Mar 2014 11:52:18 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: KK , "opsec@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ZQc9yx2b7llNXvfYmLqqJlKAgzw Subject: Re: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 14:52:50 -0000 KK, No IPRs that I know of. Cheers, Fernando On 03/13/2014 02:45 PM, KK wrote: > Dear OpSec WG, > > Be not alarmed. > This email was created to satisfy RFC 6702 "Promoting Compliance with > Intellectual Property Rights (IPR)" > (http://tools.ietf.org/rfc/rfc6702.txt). > > > The authors of draft-ietf-opsec-dhcpv6-shield > have > asked for a Working Group Last Call. Before issuing the Working Group > Last Call, we would like to check whether any claims of Intellectual > Property Rights (IPR) on the document have not yet been disclosed. > > > Are you personally aware of any IPR that applies > to draft-ietf-opsec-dhcpv6-shield > ? If > so, has this IPR been disclosed in compliance with IETF IPR rules? > > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > > If you are a document author or listed contributor on this document, > please reply to this email regardless of whether or not you are > personally aware of any relevant IPR. We might not be able to advance > this document to the next stage until we have received a reply from each > author and listed contributor. > > > If you are on the OpSec WG email list but are not an author or listed > contributor for this document, you are reminded of your opportunity for > a voluntary IPR disclosure under BCP 79. Please do not reply unless you > want to make such a voluntary disclosure. > > > Online tools for filing IPR disclosures can be found at > . > > > Thanks, > > KK > > (as OpSec WG co-chair) > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Tue Mar 18 01:40:57 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372D61A03BD for ; Tue, 18 Mar 2014 01:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URFeDCEOMEjp for ; Tue, 18 Mar 2014 01:40:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 08A0D1A03A7 for ; Tue, 18 Mar 2014 01:40:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCE33707; Tue, 18 Mar 2014 08:40:45 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Mar 2014 08:40:42 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 18 Mar 2014 08:40:44 +0000 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.8]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Tue, 18 Mar 2014 16:40:40 +0800 From: "Liushucheng (Will)" To: Fernando Gont , KK , "opsec@ietf.org" Thread-Topic: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-dhcpv6-shield Thread-Index: AQHPPuQHV8fwxo+/kU6qMcsqZARmS5rgJhkAgAZnX9A= Date: Tue, 18 Mar 2014 08:40:40 +0000 Message-ID: References: <532317A2.5040408@si6networks.com> In-Reply-To: <532317A2.5040408@si6networks.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/QXOEyLrrBaaQg_yE9KY5yW9bem0 Subject: Re: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 08:40:56 -0000 Hi KK, None from my side. Regards, Shucheng (Will) > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Fernando Gont > Sent: Friday, March 14, 2014 10:52 PM > To: KK; opsec@ietf.org > Subject: Re: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft- > ietf-opsec-dhcpv6-shield >=20 > KK, >=20 > No IPRs that I know of. >=20 > Cheers, > Fernando >=20 >=20 >=20 >=20 > On 03/13/2014 02:45 PM, KK wrote: > > Dear OpSec WG, > > > > Be not alarmed. > > This email was created to satisfy RFC 6702 "Promoting Compliance with > > Intellectual Property Rights (IPR)" > > (http://tools.ietf.org/rfc/rfc6702.txt). > > > > > > The authors of draft-ietf-opsec-dhcpv6-shield > > > have > > asked for a Working Group Last Call. Before issuing the Working > Group > > Last Call, we would like to check whether any claims of Intellectual > > Property Rights (IPR) on the document have not yet been disclosed. > > > > > > Are you personally aware of any IPR that applies to > > draft-ietf-opsec-dhcpv6-shield > > ? > If > > so, has this IPR been disclosed in compliance with IETF IPR rules? > > > > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > > > > > If you are a document author or listed contributor on this document, > > please reply to this email regardless of whether or not you are > > personally aware of any relevant IPR. We might not be able to > advance > > this document to the next stage until we have received a reply from > > each author and listed contributor. > > > > > > If you are on the OpSec WG email list but are not an author or listed > > contributor for this document, you are reminded of your opportunity > > for a voluntary IPR disclosure under BCP 79. Please do not reply > > unless you want to make such a voluntary disclosure. > > > > > > Online tools for filing IPR disclosures can be found at > > . > > > > > > Thanks, > > > > KK > > > > (as OpSec WG co-chair) > > > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > >=20 >=20 > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From nobody Tue Mar 18 04:43:25 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA4D1A03CE for ; Tue, 18 Mar 2014 04:43:20 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6JOIVdr-07g for ; Tue, 18 Mar 2014 04:43:10 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.110]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBA61A03F9 for ; Tue, 18 Mar 2014 04:43:10 -0700 (PDT) Received: from [216.82.253.163:62858] by server-14.bemta-7.messagelabs.com id B6/7E-25548-64138235; Tue, 18 Mar 2014 11:43:02 +0000 X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-9.tower-166.messagelabs.com!1395142981!12449730!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=resmed.com,-,- X-VirusChecked: Checked Received: (qmail 20227 invoked from network); 18 Mar 2014 11:43:01 -0000 Received: from unknown (HELO mail.resmed.de) (195.234.33.10) by server-9.tower-166.messagelabs.com with SMTP; 18 Mar 2014 11:43:01 -0000 Received: from GE2EML2K1002.corp.resmed.org ([172.17.6.117]) by mail.resmed.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Mar 2014 12:43:00 +0100 Received: from GE2EML2K1003.corp.resmed.org ([fe80::8547:a85:1c2d:a4bd]) by GE2EML2K1002.corp.resmed.org ([fe80::f03c:7713:9fd9:8984%17]) with mapi id 14.01.0355.002; Tue, 18 Mar 2014 12:43:00 +0100 From: Marco Ermini To: "Liushucheng (Will)" , Fernando Gont , KK , "opsec@ietf.org" Thread-Topic: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-dhcpv6-shield Thread-Index: AQHPPuQNMaFUmUfQ0UebnovwDYCa2prgm3IAgAXhfgCAAEOmcA== Date: Tue, 18 Mar 2014 11:43:00 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C469F8D20@GE2EML2K1003.corp.resmed.org> References: <532317A2.5040408@si6networks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.87] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 18 Mar 2014 11:43:00.0795 (UTC) FILETIME=[370E48B0:01CF429F] Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/M3cG4ZiiVnZV1FiJB5ZMoKt4nTk Subject: Re: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 11:43:20 -0000 Not from me as well. Marco Ermini Senior IT Security and Compliance Analyst D=A0+49 (0)899 901 1523 =A0M=A0+49 (0)175 439 5642 ResMed Germany Inc=A0Fraunhofer Str. 16 - 82152 - Martinsried - Germany ResMed.com -----Original Message----- From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Liushucheng (Will= ) Sent: Tuesday, March 18, 2014 9:41 AM To: Fernando Gont; KK; opsec@ietf.org Subject: Re: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-iet= f-opsec-dhcpv6-shield Hi KK, None from my side. Regards, Shucheng (Will) > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Fernando Gont > Sent: Friday, March 14, 2014 10:52 PM > To: KK; opsec@ietf.org > Subject: Re: [OPSEC] DON'T PANIC: Reminder about IPR relating to=20 > draft- ietf-opsec-dhcpv6-shield >=20 > KK, >=20 > No IPRs that I know of. >=20 > Cheers, > Fernando >=20 >=20 >=20 >=20 > On 03/13/2014 02:45 PM, KK wrote: > > Dear OpSec WG, > > > > Be not alarmed. > > This email was created to satisfy RFC 6702 "Promoting=20Compliance=20 > > with Intellectual Property Rights (IPR)" > > (http://tools.ietf.org/rfc/rfc6702.txt). > > > > > > The authors of draft-ietf-opsec-dhcpv6-shield=20 > > > have > > asked for a Working Group Last Call. Before issuing the Working > Group > > Last Call, we would like to check whether any claims of Intellectual=20= > > Property Rights (IPR) on the document have not yet been disclosed. > > > > > > Are you personally aware of any IPR that applies to=20 > > draft-ietf-opsec-dhcpv6-shield=20 > > ? > If > > so, has this IPR been disclosed in compliance with IETF IPR rules? > > > > (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > > > > > If you are a document author or listed contributor on this document,=20= > > please reply to this email regardless of whether or not you are=20 > > personally aware of any relevant IPR. We might not be able to > advance > > this document to the next stage until we have received a reply from=20= > > each author and listed contributor. > > > > > > If you are on the OpSec WG email list but are not an author or=20 > > listed contributor for this document, you are reminded of your=20 > > opportunity for a voluntary IPR disclosure under BCP 79. Please do=20= > > not reply unless you want to make such a voluntary disclosure. > > > > > > Online tools for filing IPR disclosures can be found at=20 > > . > > > > > > Thanks, > > > > KK > > > > (as OpSec WG co-chair) > > > > > > _______________________________________________ > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > >=20 >=20 > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=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 ---------------------------------------------------------------------- Warning: Copyright ResMed. Where the contents of this email and/or attac= hment includes materials prepared by ResMed, the use of those materials is subject exclusively to the conditions of engagement between R= esMed and the intended recipient. This communication is confidential and = may contain legally privileged information. By the use of email over the = Internet or other communication systems, ResMed is not waiving either conf= identiality of, or legal privilege in, the content of the email and of any= attachments. If the recipient of this message is not the intended addres= see, please call ResMed immediately on 1 (800) 424-0737 USA. ---------------------------------------------------------------------- From nobody Sun Mar 23 07:57:20 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998CD1A6FC5 for ; Sun, 23 Mar 2014 07:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkLPvNiAYZ_J for ; Sun, 23 Mar 2014 07:57:15 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3A06A1A6FC3 for ; Sun, 23 Mar 2014 07:57:15 -0700 (PDT) Received: from mb-aye.lan (50-0-150-57.dsl.static.sonic.net [50.0.150.57]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s2NEvCAj067273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 23 Mar 2014 14:57:13 GMT (envelope-from joelja@bogus.com) Message-ID: <532EF647.1030201@bogus.com> Date: Sun, 23 Mar 2014 07:57:11 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0 MIME-Version: 1.0 To: "opsec@ietf.org" , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , opsec chairs X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U4aIQjbqiwdrQJjhplpHJgfM9CTUnKbA2" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sun, 23 Mar 2014 14:57:14 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/0zsYPcQLt7H1aIVXLuIkBoEkdaM Subject: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 14:57:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U4aIQjbqiwdrQJjhplpHJgfM9CTUnKbA2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I hope that you folks are recovering well from IETF meeting related excesses and accompanying travel. Some questions came up in the IESG review of the document that are more appropriately answered by the working group rather than by me attempting to channel you folks. https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ 1. Does the working-group view view disabling IPV6 in deployed equipment due to operational necessity as a desirable outcome. 2. Does the working-group characterize the problem of vpn leakages captured in this document as being distinct from the problems posed by split-tunnels in general. Your thoughts would be appreciated. joel --U4aIQjbqiwdrQJjhplpHJgfM9CTUnKbA2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEUEARECAAYFAlMu9kcACgkQ8AA1q7Z/VrI9nwCcCoeHijMeNyAXkRXJozxzcYYy /5kAmJ+JVRcmhGcspKtxTXI4Eg3GH+k= =dZTI -----END PGP SIGNATURE----- --U4aIQjbqiwdrQJjhplpHJgfM9CTUnKbA2-- From nobody Sun Mar 23 10:39:58 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0CD1A6FF4 for ; Sun, 23 Mar 2014 10:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1K1po1vOovN for ; Sun, 23 Mar 2014 10:39:53 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 825041A6FF3 for ; Sun, 23 Mar 2014 10:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2476; q=dns/txt; s=iport; t=1395596393; x=1396805993; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tJAFdrnslMBFErT3etj5WXlFn1aZEuXQ/25TcbMSFFM=; b=Xny17kDHk42wpfiuSCx7PRhHO6I3dvddbDdEgGYj56bDM8YIad8+fDxj dqoTLl3CZ2xQXr8cDCFAihB+5H4xXaEdfuVDNCvrHa5HmjTNLaFLyyJTT eI15naeALojfwkUfEsHPu2zTcJEypO8eyakj830lwPk1RzczEAWngkvcj U=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAHwbL1OtJXG8/2dsb2JhbABZgwY7V7s0hzqBDxZ0giUBAQEDAQEBAWsLBQsCAQhGJwslAgQOBQkFh2MIDc0rF44pAQFPAgWDJIEUBJBTgTSGQ5Ixgy2Bcjk X-IronPort-AV: E=Sophos;i="4.97,715,1389744000"; d="asc'?scan'208";a="29690949" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-1.cisco.com with ESMTP; 23 Mar 2014 17:39:52 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2NHdq0Y001602 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Mar 2014 17:39:52 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.176]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Sun, 23 Mar 2014 12:39:52 -0500 From: "Carlos Pignataro (cpignata)" To: Joel Jaeggli Thread-Topic: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. Thread-Index: AQHPRqg0oB63EgVi6ES/51HfmquRHZrvREyA Date: Sun, 23 Mar 2014 17:39:51 +0000 Message-ID: References: <532EF647.1030201@bogus.com> In-Reply-To: <532EF647.1030201@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.208.10] Content-Type: multipart/signed; boundary="Apple-Mail=_F91817F8-D80D-47B4-8321-321D88C0223A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/DeHFwXqiERIMVP1G3-gO-weyj44 Cc: "opsec@ietf.org" , opsec chairs , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 17:39:55 -0000 --Apple-Mail=_F91817F8-D80D-47B4-8321-321D88C0223A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Joel, Warren (as shepherd), In addition to some responses below, it appears that my review comments = sent to opsec are yet to be addressed: http://www.ietf.org/mail-archive/web/opsec/current/msg01477.html "The only remaining bit is the issue raised by Carlos which = we'll hopefully address in the next rev." http://www.ietf.org/mail-archive/web/opsec/current/msg01447.html It seems the remaining bit is still remaining. Frankly, I am still = concerned that this doc still refers to "VPN Leakages" while its = applicability and scope is a small subset of "VPNs". More inline. On Mar 23, 2014, at 10:57 AM, joel jaeggli wrote: > Hi, >=20 > I hope that you folks are recovering well from IETF meeting related > excesses and accompanying travel. >=20 > Some questions came up in the IESG review of the document that are = more > appropriately answered by the working group rather than by me = attempting > to channel you folks. >=20 > https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ >=20 > 1. Does the working-group view view disabling IPV6 in deployed = equipment > due to operational necessity as a desirable outcome. My personal view is "No". That would be a step backwards in deploying = IPv6. >=20 > 2. Does the working-group characterize the problem of vpn leakages > captured in this document as being distinct from the problems posed by > split-tunnels in general. >=20 I do not think it is different. Rather, this is one instantiation of a = more general problem. Thanks, -- Carlos. > Your thoughts would be appreciated. > joel >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_F91817F8-D80D-47B4-8321-321D88C0223A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlMvHGkACgkQtfDPGTp3USyKgwCcDaGox3vYlVxVoXqr0fJSMYmN 6aYAmgMgQF+nh7om9fPd0Axjm4OM7eHr =PNa4 -----END PGP SIGNATURE----- --Apple-Mail=_F91817F8-D80D-47B4-8321-321D88C0223A-- From nobody Mon Mar 24 07:20:14 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E705E1A0219 for ; Mon, 24 Mar 2014 07:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.811 X-Spam-Level: X-Spam-Status: No, score=-6.811 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6bq-bkkyfLM for ; Mon, 24 Mar 2014 07:20:10 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 466181A01F9 for ; Mon, 24 Mar 2014 07:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2535; q=dns/txt; s=iport; t=1395670809; x=1396880409; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5DuO3HKX8j0GtUm18BF9cPYd+dGbhVysZ1GzyNTZGy0=; b=EGRxGTWoXGHJ8gm8Rup2KwjSWYDpAe8OfMiCZiao+rU2kRMqPCKWrK+3 I/ldGno05APsVBeKmO2BM0BDJtq2DmkhpYDjxbuvH6fC1gvvDfZCUCfU1 ICYUcpxHb3ZomxEcRtSoXP6734QRBopPpn8zEvoUQKo3Wq6sUaAwxCv8G A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAGs+MFOtJV2c/2dsb2JhbABZgwY7V7s4hzWBFhZ0giUBAQEEAQEBNzQGEQQCAQgOAwQBAQEKFAkHJwsUCQgCBAESCAGHcA3OIheOGBEBHzgGgx6BFASZfJB/gW+BPoFyOQ X-IronPort-AV: E=Sophos;i="4.97,721,1389744000"; d="scan'208";a="29878717" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 24 Mar 2014 14:20:09 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2OEK9FL025115 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 14:20:09 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.194]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 09:20:09 -0500 From: "Gunter Van de Velde (gvandeve)" To: Fernando Gont , KK , "opsec@ietf.org" Thread-Topic: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-dhcpv6-shield Thread-Index: AQHPPuQIRV+urSxH+0eWlAOAfUhdo5rhAAcAgA9aZhA= Date: Mon, 24 Mar 2014 14:20:08 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B241137BBE0@xmb-aln-x12.cisco.com> References: <532317A2.5040408@si6networks.com> In-Reply-To: <532317A2.5040408@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.194.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/_PGeOu0FVQF0ACsxAJjBCckCGME Subject: Re: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 14:20:12 -0000 KK, Not aware of any IPR. Cheers, G/ -----Original Message----- From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Fernando Gont Sent: 14 March 2014 15:52 To: KK; opsec@ietf.org Subject: Re: [OPSEC] DON'T PANIC: Reminder about IPR relating to draft-ietf= -opsec-dhcpv6-shield KK, No IPRs that I know of. Cheers, Fernando On 03/13/2014 02:45 PM, KK wrote: > Dear OpSec WG, >=20 > Be not alarmed. > This email was created to satisfy RFC 6702 "Promoting Compliance with=20 > Intellectual Property Rights (IPR)" > (http://tools.ietf.org/rfc/rfc6702.txt). >=20 >=20 > The authors of draft-ietf-opsec-dhcpv6-shield=20 > have=20 > asked for a Working Group Last Call. Before issuing the Working Group=20 > Last Call, we would like to check whether any claims of Intellectual=20 > Property Rights (IPR) on the document have not yet been disclosed. >=20 >=20 > Are you personally aware of any IPR that applies to=20 > draft-ietf-opsec-dhcpv6-shield=20 > ? If=20 > so, has this IPR been disclosed in compliance with IETF IPR rules? >=20 > (See RFCs 3979, 4879, 3669, and 5378 for more details.) >=20 >=20 > If you are a document author or listed contributor on this document,=20 > please reply to this email regardless of whether or not you are=20 > personally aware of any relevant IPR. We might not be able to advance=20 > this document to the next stage until we have received a reply from=20 > each author and listed contributor. >=20 >=20 > If you are on the OpSec WG email list but are not an author or listed=20 > contributor for this document, you are reminded of your opportunity=20 > for a voluntary IPR disclosure under BCP 79. Please do not reply=20 > unless you want to make such a voluntary disclosure. >=20 >=20 > Online tools for filing IPR disclosures can be found at=20 > . >=20 >=20 > Thanks, >=20 > KK >=20 > (as OpSec WG co-chair) >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 -- 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 nobody Mon Mar 24 08:51:50 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB161A025F; Mon, 24 Mar 2014 08:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Do8FEG_LCti3; Mon, 24 Mar 2014 08:51:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C651A01BE; Mon, 24 Mar 2014 08:51:35 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> Date: Mon, 24 Mar 2014 08:51:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/6QaSLL2tzU8KpMYVzgwut_uiRIE Cc: opsec@ietf.org Subject: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 15:51:38 -0000 The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Using Only Link-Local Addressing Inside an IPv6 Network' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-04-07. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Mar 24 11:30:47 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD1C1A026F for ; Mon, 24 Mar 2014 11:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.225 X-Spam-Level: ** X-Spam-Status: No, score=2.225 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juvq01dSZLdE for ; Mon, 24 Mar 2014 11:30:44 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5131A024C for ; Mon, 24 Mar 2014 11:30:20 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,722,1389762000"; d="scan'208";a="247569412" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 Mar 2014 14:29:25 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 24 Mar 2014 14:30:12 -0400 From: "George, Wes" To: joel jaeggli , "opsec@ietf.org" , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , opsec chairs Date: Mon, 24 Mar 2014 14:30:12 -0400 Thread-Topic: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. Thread-Index: Ac9HjxflZ1q+5I7TTLWTXqo3Deu5VA== Message-ID: References: <532EF647.1030201@bogus.com> In-Reply-To: <532EF647.1030201@bogus.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/VK0Fdv87Tby3ob8zc41D5rQ7vKE Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Mar 2014 18:30:45 -0000 DQpPbiAzLzIzLzE0LCAxMDo1NyBBTSwgImpvZWwgamFlZ2dsaSIgPGpvZWxqYUBib2d1cy5jb20+ IHdyb3RlOg0KDQo+DQo+MS4gRG9lcyB0aGUgd29ya2luZy1ncm91cCB2aWV3IHZpZXcgZGlzYWJs aW5nIElQVjYgaW4gZGVwbG95ZWQgZXF1aXBtZW50DQo+ZHVlIHRvIG9wZXJhdGlvbmFsIG5lY2Vz c2l0eSBhcyBhIGRlc2lyYWJsZSBvdXRjb21lLg0KDQpXZWxsLCBJIHRoaW5rIHRoZSBhbnN3ZXIg dGhlcmUgaXMgbm8uIEkga25vdyB3ZSBhZGRlZCBhIGdvb2QgYml0IG9mIHRleHQNCnRvIDcxMjMg dG8gbWFrZSBpdCBjbGVhcmVyIHRoYXQgd2Ugd2VyZSB3cml0aW5nIHRoaXMgZm9yIGNvbXBsZXRl bmVzc+KAmQ0Kc2FrZSwgbm90IHRvIGFkdm9jYXRlIGRpc2FibGluZyBJUHY2IGFzIGFuIG91dGNv bWUuDQoNCldlcw0KDQoNClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1h eSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGlj aCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJl bG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBp cyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhp cyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRo ZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkg cHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUt bWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Tue Mar 25 11:09:06 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1EF1A01F8 for ; Tue, 25 Mar 2014 11:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSearOM4xMzw for ; Tue, 25 Mar 2014 11:08:47 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id B30A91A01F3 for ; Tue, 25 Mar 2014 11:08:46 -0700 (PDT) Received: from [2001:5c0:1000:a::a11] by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSVm3-0005cG-Ni; Tue, 25 Mar 2014 19:08:32 +0100 Message-ID: <5331C1B0.4060508@si6networks.com> Date: Tue, 25 Mar 2014 17:49:36 +0000 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: joel jaeggli , "opsec@ietf.org" , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , opsec chairs References: <532EF647.1030201@bogus.com> In-Reply-To: <532EF647.1030201@bogus.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/2qMfdIy8WKFEX7q-EYrzHeTcLZM Cc: Sean Turner , Paul Hoffman Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 18:08:50 -0000 Hi, Joel, On 03/23/2014 02:57 PM, joel jaeggli wrote: > > https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ > > 1. Does the working-group view view disabling IPV6 in deployed > equipment due to operational necessity as a desirable outcome. This should not be characterized as a "desired outcome". The document describes a problem, and discusses possible mitigations. It never says or suggests that this is the desired outcome -- if anything, just a possible "last resort" scenario. For instance, this is what the document says: "While the desired mitigation for the issues discussed in this document is for VPN clients to be IPv6-aware, we note that in scenarios where this would be unfeasible, and administrator may want to disable IPv6 connectivity on all network interfaces of the node employing the IPv6-unaware VPN client." As a guy that both normally employs IPv6 and that also employs an IPv6-unaware client (OpenVPN), I face this problem very frequently. What I usually do is that, whenever I really mean to employ my VPN client, I resort to disabling IPv6. This is certainly not a desired outcome... but a tradeoff between "having my taffic sent out in the clear when I mean it to be encrypted" and "employing IPv6". The desired outcome (albeit noted in the I-D) is that VPN clients successfully support IPv6. But at times this not under the control of the folk employing the VPN client. > 2. Does the working-group characterize the problem of vpn leakages > captured in this document as being distinct from the problems posed > by split-tunnels in general. The problem is different because this problem arises from a (usually overseen) interaction between the two protocols (which are usually assumed to be separate worlds). FWIW, this wan not only discussed in opsec, but we also presented this document in at the ipsecme wg. 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 nobody Tue Mar 25 15:43:30 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BF21A0168; Tue, 25 Mar 2014 15:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0-43c4kR679; Tue, 25 Mar 2014 15:41:21 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 23E2B1A0259; Tue, 25 Mar 2014 15:41:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WSa1j-00087K-J3; Tue, 25 Mar 2014 22:41:00 +0000 Date: Wed, 26 Mar 2014 07:40:58 +0900 Message-ID: From: Randy Bush To: The IESG In-Reply-To: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/drYUcBwwPbO4Nb7kWdCLuNUw5nE X-Mailman-Approved-At: Tue, 25 Mar 2014 15:43:26 -0700 Cc: opsec@ietf.org Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 22:41:23 -0000 this documents a bad idea. you may notice that it is a vendor, not operator document. it makes the network harder to operate, harder to debug, ... please do not let this out without a toxic warning sign. randy From nobody Tue Mar 25 15:48:41 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515BC1A0248; Tue, 25 Mar 2014 15:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.553 X-Spam-Level: X-Spam-Status: No, score=-100.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1Jupt8hMQG7; Tue, 25 Mar 2014 15:48:31 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 725BD1A01C6; Tue, 25 Mar 2014 15:48:31 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2PMmTEm002973; Tue, 25 Mar 2014 22:48:29 GMT Received: from 950129200 (110.26.90.92.rev.sfr.net [92.90.26.110]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s2PMmRQF002951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Mar 2014 22:48:28 GMT From: "Adrian Farrel" To: "'Randy Bush'" References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 25 Mar 2014 22:48:28 -0000 Message-ID: <05c401cf487c$579bb300$06d31900$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG6BlameiIltoh+WJywFMLMwpOFGgEGVbvsmxS4p0A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20590.002 X-TM-AS-Result: No--10.862-10.0-31-10 X-imss-scan-details: No--10.862-10.0-31-10 X-TMASE-MatchedRID: csPTYAMX1+Ezx9GDMr0HvzYTypjB3iDVuikHZcC6ceATVJPv0YKEKWn7 AlTb8W2x5JSNuB3sHCuIGSNBXE+7xzpI0A0aNTmU5gCHftmwEMK3dp6DuD+6wC62hjZS0WoYwqK BAza4rVvv7KQvOHjFKJLiv6y4vDKVT6v5kSMZF7220BbG4zmyXl/KLhhqzeBNN2WxgvaD/zssgd kHScxUMRb6djK7WmZ8kZOl7WKIImq0P2qkGU0XytAtbEEX0MxBxEHRux+uk8h+ICquNi0WJMaMK lIG+20sgJ9/MrOPS1BUWWESK6nWHw3HxxxB7MViftwZ3X11IV0= Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/1-2OkjeN0hzdF1KJ0HKxYhKE8M0 Cc: opsec@ietf.org, 'The IESG' Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 22:48:33 -0000 Hi Randy, For my enlightenment, are you saying: a. The benefits are over-hyped in this document and the issues with drawbacks are not sufficiently highlighted. b. The very existence of this document is a problem I think the answer to that might guide how the community responds to your review. Thanks, Adrian > -----Original Message----- > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Randy Bush > Sent: 25 March 2014 22:41 > To: The IESG > Cc: opsec@ietf.org > Subject: Re: Last Call: (Using Only Link-Local > Addressing Inside an IPv6 Network) to Informational RFC > > this documents a bad idea. you may notice that it is a vendor, not > operator document. it makes the network harder to operate, harder to > debug, ... > > please do not let this out without a toxic warning sign. > > randy From nobody Tue Mar 25 15:49:27 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42E61A0205; Tue, 25 Mar 2014 15:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUnfbydK1dus; Tue, 25 Mar 2014 15:49:18 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 754DF1A01C6; Tue, 25 Mar 2014 15:49:18 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 749EB1B8067; Tue, 25 Mar 2014 15:49:17 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 6D5B1190043; Tue, 25 Mar 2014 15:49:17 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Mar 2014 15:49:17 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 25 Mar 2014 17:49:15 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> To: Randy Bush X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/g6B-PpuRtTGYEknNM66JBZ4c8-g Cc: opsec@ietf.org, The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 22:49:20 -0000 On Mar 25, 2014, at 5:40 PM, Randy Bush wrote: > this documents a bad idea. you may notice that it is a vendor, not > operator document. it makes the network harder to operate, harder to > debug, ... It does this because...? Last call review comments are greatly appreciated, _if_ they raise = technical issues; it sounds like you think there's a technical issue = here, but since you haven't said what it is, you aren't giving us any = reason to take you seriously. From nobody Tue Mar 25 16:07:31 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E921A027B; Tue, 25 Mar 2014 16:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9G9z57PXDsg3; Tue, 25 Mar 2014 16:07:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB8D1A0256; Tue, 25 Mar 2014 16:07:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WSaRA-0008D8-QM; Tue, 25 Mar 2014 23:07:17 +0000 Date: Wed, 26 Mar 2014 08:07:15 +0900 Message-ID: From: Randy Bush To: Adrian Farrel In-Reply-To: <05c401cf487c$579bb300$06d31900$@olddog.co.uk> References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <05c401cf487c$579bb300$06d31900$@olddog.co.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/6TQPM4PH2FZGjk2yFfmgal1pGwQ Cc: opsec@ietf.org, The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 23:07:22 -0000 > a. The benefits are over-hyped in this document and the issues with drawbacks > are not sufficiently highlighted. yes > b. The very existence of this document is a problem in all honesty, i think this should be junked. but that is unrealistic. so i will settle for a toxic label. randy From nobody Tue Mar 25 17:06:16 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5351A026D; Tue, 25 Mar 2014 17:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76ZDQTvNgz3C; Tue, 25 Mar 2014 17:06:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 235B01A025D; Tue, 25 Mar 2014 17:06:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WSbM4-0008Mn-LX; Wed, 26 Mar 2014 00:06:05 +0000 Date: Wed, 26 Mar 2014 09:06:03 +0900 Message-ID: From: Randy Bush To: Ted Lemon In-Reply-To: <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/NsYQI99voCR2OYy_-ploadWSx7w Cc: opsec@ietf.org, The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 00:06:10 -0000 for those who seem not to have followed the ops discussions on 1918 links, this how operators think From: sthaug@nethelp.no Subject: Re: Link addressing (was: Re: A Plea for Architectural & Specification Stability with IPv6) To: markzzzsmith@yahoo.com.au Cc: ipv6@ietf.org Date: Tue, 25 Mar 2014 09:46:26 +0100 (CET) > The question I've wondered a bit about is what is the common > operational or implementation practice when configuring manual > addresses on routers. > > For people who configure static addresses on router interfaces, do > they actively switch SLAAC off for either individual prefixes, or > for the whole interface? Answering only for myself, obviously: - We use static /124 addresses on our router-router links, which means we're pretty darn sure that SLAAC won't be working for anything other than the link local address. We may switch to /127. - Additionally, Juniper routers need explicit configuration to turn on RA. We definitely don't configure this on our router-router links. - Additionally, we're planning to explicitly turn off SLAAC on Cisco routers for our router-router links. > Alternatively, if SLAAC is left enabled for the LL prefix, then > there is likely to now be two LLs on the interface. Static > configuration of an LL address would usually indicate preference for > its use for all LL traffic over the SLAAC LL address, which may be a > problem, because IIRC, RFC6724 doesn't place any preference for > static addresses over SLAAC addresses. The static IPv6 addresses that we configure on router-router links are *not* link local. Thus we don't have two link local addresses on the interfaces. Steinar Haug, AS 2116 From nobody Tue Mar 25 17:57:18 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7291A0275; Tue, 25 Mar 2014 17:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Unp-nQHWF8kj; Tue, 25 Mar 2014 17:57:08 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 180E71A026E; Tue, 25 Mar 2014 17:57:07 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 61A381B8067; Tue, 25 Mar 2014 17:57:06 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 52061190043; Tue, 25 Mar 2014 17:57:06 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Mar 2014 17:57:06 -0700 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: Date: Tue, 25 Mar 2014 19:57:04 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> To: Randy Bush X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/gLHCPSe6nH07Wb7yIrn5yfuRBJc Cc: opsec@ietf.org, The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 00:57:10 -0000 On Mar 25, 2014, at 7:06 PM, Randy Bush wrote: > for those who seem not to have followed the ops discussions on 1918 > links, this how operators think That's better than the previous response, but still doesn't communicate = a compelling issue. You're statically configuring IP addresses on the = /124; that's no easier or harder than statically configuring IP = addresses link-locally. I don't mean to say that you are wrong=97just that you're not giving us = much to work with. From nobody Wed Mar 26 03:21:37 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C31AD1A030F for ; Wed, 26 Mar 2014 03:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_54=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXsCEMQxPSpl for ; Wed, 26 Mar 2014 03:21:33 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id F3A1A1A030A for ; Wed, 26 Mar 2014 03:21:32 -0700 (PDT) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 4A92860B08 for ; Wed, 26 Mar 2014 11:21:30 +0100 (CET) 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 12A44604B0 for ; Wed, 26 Mar 2014 11:21:30 +0100 (CET) Received: (qmail 13796 invoked by uid 1007); 26 Mar 2014 11:21:30 +0100 Date: Wed, 26 Mar 2014 11:21:30 +0100 From: Gert Doering To: Ted Lemon Message-ID: <20140326102130.GR43641@Space.Net> References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/nyy9HmxhwxWdq153iYQH6DS8464 Cc: Randy Bush , opsec@ietf.org, The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 10:21:35 -0000 Hi, On Tue, Mar 25, 2014 at 07:57:04PM -0500, Ted Lemon wrote: > On Mar 25, 2014, at 7:06 PM, Randy Bush wrote: > > for those who seem not to have followed the ops discussions on 1918 > > links, this how operators think > > That's better than the previous response, but still doesn't communicate a compelling issue. You're statically configuring IP addresses on the /124; that's no easier or harder than statically configuring IP addresses link-locally. > > I don't mean to say that you are wrong?just that you're not giving us much to work with. If you go back, I have commented on that draft that we'll never ever go link-local-only, because the drawbacks of not being able to specifically ping one particular interface from the management system, and not having traceroute tell me on which exact path my packets are flowing are not acceptable. YMMV on this, of course. I don't particulary object to having a RFC out there that says "it can be done, but this is just one option, and drawbacks exist" - which the text does. I just won't ever *do* that. 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 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Wed Mar 26 03:23:36 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB451A0304; Wed, 26 Mar 2014 03:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRbXLKbXDA7K; Wed, 26 Mar 2014 03:23:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id D775E1A0300; Wed, 26 Mar 2014 03:23:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WSkzS-0001Sh-CP; Wed, 26 Mar 2014 10:23:22 +0000 Date: Wed, 26 Mar 2014 19:23:20 +0900 Message-ID: From: Randy Bush To: Gert Doering In-Reply-To: <20140326102130.GR43641@Space.Net> References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/1dn-P-Fba7nDvzyw01D7R_dZsUY Cc: opsec@ietf.org, Ted Lemon , The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 10:23:30 -0000 > I don't particulary object to having a RFC out there that says "it can > be done, but this is just one option, and drawbacks exist" - which the > text does. I just won't ever *do* that. the problem is that the naive will fall into the hole. hence my assertion that it needs the toxic warning. From nobody Wed Mar 26 05:42:07 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19EC1A0324; Wed, 26 Mar 2014 05:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeD6wCTQ9I2B; Wed, 26 Mar 2014 05:42:01 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id C8E791A0322; Wed, 26 Mar 2014 05:42:00 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7A51A8815E; Wed, 26 Mar 2014 05:41:59 -0700 (PDT) Received: from 10252181.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E52BF71B0001; Wed, 26 Mar 2014 05:41:58 -0700 (PDT) Message-ID: <5332CB15.2090600@innovationslab.net> Date: Wed, 26 Mar 2014 08:41:57 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Randy Bush , Gert Doering References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a92nbpUoTO6Pm9M6Tvws7N6CJUc5s39Dp" Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/8rsPWeEUB8AcTYHKadLQYS_FV-Q Cc: opsec@ietf.org, Ted Lemon , The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 12:42:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a92nbpUoTO6Pm9M6Tvws7N6CJUc5s39Dp Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Randy, On 3/26/14 6:23 AM, Randy Bush wrote: >> I don't particulary object to having a RFC out there that says "it can= >> be done, but this is just one option, and drawbacks exist" - which the= >> text does. I just won't ever *do* that. >=20 > the problem is that the naive will fall into the hole. hence my > assertion that it needs the toxic warning. >=20 Let me be explicit for those who need it... Operating with only link-local addresses isolates the devices from management systems located in a NOC (i.e., not directly adjacent). A typical first-step diagnostic when something goes wrong is to ping the address of the suspect interface *from the NOC*. That can't be done if the pesky device only has a link-local address. I agree with Randy's pov that this document has some serious issues. Regards, Brian --a92nbpUoTO6Pm9M6Tvws7N6CJUc5s39Dp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTMssaAAoJEBOZRqCi7goqFaAIAKlOyfIXHSiynPVXCxzroObI dW2V0xmAVY802yeeMPA52dc68hz8Xd+MzD+P583G4/3brmXVkdFIR5A4/ryDSUNq BMXuNZ5WvaoZGKe3+DDHDOXh3Y/tPLiWsYQJKMg133S4byNDOKjhIe3sWjXHmWJv lKvadv1Y7n38cgl/w1fsNyjkgPflTmG2rYOs8PT81Jb6dlnR+twjOAq0nJ6R6m2V Hcsef7pBdPMnuZGbsQR4nDDdZdH/qXE6elycP9gytu3xalJCjVCoCliPTOa9mTq7 g9TeB7BRH3KSMq3aciqLwMxqhpPDU8F+Qlf0lY5d25nnTD0hQlr+7QKLG0+U74w= =YbNb -----END PGP SIGNATURE----- --a92nbpUoTO6Pm9M6Tvws7N6CJUc5s39Dp-- From nobody Wed Mar 26 06:43:33 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96C31A0351; Wed, 26 Mar 2014 06:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FxeL7ysSTiS; Wed, 26 Mar 2014 06:43:21 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id DFF781A02D8; Wed, 26 Mar 2014 06:43:21 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C7F0B1B803B; Wed, 26 Mar 2014 06:43:20 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id C148F190043; Wed, 26 Mar 2014 06:43:20 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 06:43:20 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <20140326102130.GR43641@Space.Net> Date: Wed, 26 Mar 2014 08:43:18 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> To: Gert Doering X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/pAwjh37dhdS0QxJrfpljkTiaUwk Cc: Randy Bush , opsec@ietf.org, The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 13:43:26 -0000 On Mar 26, 2014, at 5:21 AM, Gert Doering wrote: > If you go back, I have commented on that draft that we'll never ever = go > link-local-only, because the drawbacks of not being able to = specifically > ping one particular interface from the management system, and not = having > traceroute tell me on which exact path my packets are flowing are=20 > not acceptable. YMMV on this, of course. Thanks, that's exactly the detail I was missing. It's obvious in = hindsight, but didn't jump out at me based on Randy's comment. :} From nobody Wed Mar 26 08:10:21 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7241A0192; Wed, 26 Mar 2014 08:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.861 X-Spam-Level: X-Spam-Status: No, score=-3.861 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOCPpvOov7SY; Wed, 26 Mar 2014 08:10:06 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 140461A0119; Wed, 26 Mar 2014 08:10:03 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9D32BA2; Wed, 26 Mar 2014 16:10:01 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 95939A1; Wed, 26 Mar 2014 16:10:01 +0100 (CET) Date: Wed, 26 Mar 2014 16:10:01 +0100 (CET) From: Mikael Abrahamsson To: Ted Lemon In-Reply-To: Message-ID: References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ctxEQN9O0slGaZolmlBDBxm99ck Cc: Randy Bush , opsec@ietf.org, The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 15:10:14 -0000 On Wed, 26 Mar 2014, Ted Lemon wrote: > Thanks, that's exactly the detail I was missing. It's obvious in > hindsight, but didn't jump out at me based on Randy's comment. :} 2.3 in the draft: "Interface ping: if an interface doesn't have a routable address, it can only be pinged from a node on the same link. Therefore, it is not possible to ping a specific link interface remotely." So I don't really understand what Randy has against this document and what other warnings he wants to have in it. What is this "toxic" warning Randy wants? Randy, please enlighten me? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Wed Mar 26 09:54:20 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F4E1A0386; Wed, 26 Mar 2014 09:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaaRZ7mXOQwE; Wed, 26 Mar 2014 09:54:12 -0700 (PDT) Received: from backup.buh.org (backup.buh.org [50.56.205.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9F6181A01AF; Wed, 26 Mar 2014 09:54:12 -0700 (PDT) Received: from natpool46.buh.org (monkey.buh.org [216.27.161.131]) (authenticated bits=0) by backup.buh.org (8.14.4/8.14.4/Debian-4) with ESMTP id s2QGs9xQ003179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Mar 2014 11:54:10 -0500 Message-ID: <53330633.7070503@buh.org> Date: Wed, 26 Mar 2014 12:54:11 -0400 From: Erik Muller User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: opsec@ietf.org References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.9 (backup.buh.org [50.56.205.83]); Wed, 26 Mar 2014 11:54:11 -0500 (CDT) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/OXkbw8P3z9sHCSj9Ho-9v5W5xME Cc: The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 16:54:14 -0000 On 3/26/14, 11:10 , Mikael Abrahamsson wrote: > 2.3 in the draft: > > So I don't really understand what Randy has against this document and what > other warnings he wants to have in it. What is this "toxic" warning Randy > wants? Randy, please enlighten me? Well, not attempting to speak for Randy, but I'd like to see a more balanced introduction (it summarizes the benefits; it should not just defer the caveats to the body), and maybe some discussion on where it might be useful to deploy a network using lla-only (homenets or small meshy things? I can't think of any enterprise or carrier scenario where I would want to do this), and clearer statement that this may not be for everybody and is not a general BCP. And while the caveats hint at it, there's also an operational complexity burden that isn't called out - the ping and NMS/discovery limitations also apply to human operators troubleshooting faults and attempting to understand a deployed topology. LLDP and NDP add a layer of indirection in identifying what devices should be adjacent to a given interface, and only work when there is operational state available and links are up (whereas GUAs on interconnected devices can be compared by configuration alone, telling you what's supposed to be there). -e From nobody Wed Mar 26 14:31:33 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C561A03D7; Wed, 26 Mar 2014 14:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8Lh5N8d0V9D; Wed, 26 Mar 2014 14:31:29 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6A11A03DB; Wed, 26 Mar 2014 14:31:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WSvPv-0003CG-UZ; Wed, 26 Mar 2014 21:31:24 +0000 Date: Thu, 27 Mar 2014 06:31:22 +0900 Message-ID: From: Randy Bush To: Mikael Abrahamsson In-Reply-To: References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/vwwsOWaq0rUuYVG1vpys_1-gNXc Cc: opsec@ietf.org, Ted Lemon , The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 21:31:30 -0000 > 2.3 in the draft: > > "Interface ping: if an interface doesn't have a routable address, it > can only be pinged from a node on the same link. Therefore, it is > not possible to ping a specific link interface remotely." > > So I don't really understand what Randy has against this document and what > other warnings he wants to have in it. what is missing is "therefore all monitoring, diagnostic, management, ... tools will not work. you will be unable to maintain your network. From nobody Wed Mar 26 14:39:08 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1933C1A03CE; Wed, 26 Mar 2014 14:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0R5Bxi7-V5x; Wed, 26 Mar 2014 14:39:01 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2751A024E; Wed, 26 Mar 2014 14:39:00 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id b8so1954257lan.40 for ; Wed, 26 Mar 2014 14:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=P9FFFKDjNbbrsLv7mlNQS78gDInRj9OB3yRx3rYIT70=; b=pCbnUTDO9K4okOLOKRRd7aVxCafX0XMqY4v82GoVYX7rZQbQZRlbCZ2LkAAQoK+5bz PG+KuBezke8w0AUENPV20GMNijd5CMPTiK1wZzFA//4OwHbLWgWsUdZ1Oz0utR8CHDIx Gm80cwlV5TGXj9RX26vAqXTnnDtmh/oBiecEBUixMwE3F7XJUKksm3yw8jg3A3tF+zT3 66lTASu+NR5t6OHT2SMH4RgLQwZYrb6NYgYNmaS/Qaw42pcEXU3bff9Rpc34OQXNzLSf LBYCP1yLFOw8hpxZ0qhqlHbsZZmh9TS3HgPdNcPiMjaNm4LgGEECYSTdc7GAkmo55wXs S34Q== MIME-Version: 1.0 X-Received: by 10.112.47.3 with SMTP id z3mr7288996lbm.34.1395869938806; Wed, 26 Mar 2014 14:38:58 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.152.45.196 with HTTP; Wed, 26 Mar 2014 14:38:58 -0700 (PDT) In-Reply-To: References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> Date: Wed, 26 Mar 2014 17:38:58 -0400 X-Google-Sender-Auth: H8OwC94gBkGeRkxv1AuCTY4mwe0 Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/nNVkaT7aOaS4uXyQMt6sw-jXJek Cc: The IESG , opsec wg mailing list , Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 21:39:03 -0000 On Wed, Mar 26, 2014 at 5:31 PM, Randy Bush wrote: >> 2.3 in the draft: >> >> "Interface ping: if an interface doesn't have a routable address, it >> can only be pinged from a node on the same link. Therefore, it is >> not possible to ping a specific link interface remotely." >> >> So I don't really understand what Randy has against this document and what >> other warnings he wants to have in it. > > what is missing is "therefore all monitoring, diagnostic, management, > ... tools will not work. you will be unable to maintain your network. unless you can always be assured of testing from the device which is having problems. You could imagine an NMS/tool-set which knows: "Login to device before testing!" This also doesn't work of routing protocols for the device fail... -chris (for the record I also think it's folly to do the process in the doc, but figured grownups understood that, and less-grown-up-folks would listen or learn the hard way) From nobody Wed Mar 26 14:54:50 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE891A0241; Wed, 26 Mar 2014 14:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjY57gFx7M8U; Wed, 26 Mar 2014 14:54:47 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 50A671A0223; Wed, 26 Mar 2014 14:54:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WSvmV-0003Gj-Mc; Wed, 26 Mar 2014 21:54:44 +0000 Date: Thu, 27 Mar 2014 06:54:41 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/6cUAJjEnarubFC9xSYHLZRgUXqE Cc: The IESG , opsec wg mailing list , Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 21:54:48 -0000 > unless you can always be assured of testing from the device which is > having problems. > > You could imagine an NMS/tool-set which knows: "Login to device before testing!" > This also doesn't work of routing protocols for the device fail... i am in the noc 20 router hops away. so the code has to go hop by hop, logging in to every router en route. the sec folk will love that. you should talk to your sec folk. oh, you are your sec folk. randy From nobody Wed Mar 26 16:10:33 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77D3D1A0236; Wed, 26 Mar 2014 16:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 131616pflx9G; Wed, 26 Mar 2014 16:10:28 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 946891A0205; Wed, 26 Mar 2014 16:10:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WSwxh-0003QZ-70; Wed, 26 Mar 2014 23:10:21 +0000 Date: Thu, 27 Mar 2014 08:10:19 +0900 Message-ID: From: Randy Bush To: Brian Haberman In-Reply-To: <5332CB15.2090600@innovationslab.net> References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> <5332CB15.2090600@innovationslab.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/tYfUCwBY9GAFC_BhzqmcDFduFls Cc: The IESG , opsec@ietf.org, Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 23:10:30 -0000 > I agree with Randy's pov that this document has some serious issues. from my warped pov, the draft is a sell job which does mention many basic issues, but completely omits their really bad consequences. randy From nobody Wed Mar 26 18:34:45 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9E31A0421; Wed, 26 Mar 2014 18:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDgUxLCjDeVT; Wed, 26 Mar 2014 18:34:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2721A0275; Wed, 26 Mar 2014 18:34:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WSzDI-0003pv-83; Thu, 27 Mar 2014 01:34:36 +0000 Date: Thu, 27 Mar 2014 10:34:34 +0900 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/_luN6CfBp3QN4hC6_E-EMbFUGnM Cc: The IESG , opsec wg mailing list , Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 01:34:43 -0000 > I'm, again, not arguing FOR this configuration, just saying you could > make it work, at a price of longer outages (most likely) and more > (much MUCH more) complexity in your operations. I don't see what LLA > gets you that: > 1) put all your ptp/loops into 1 aggregate > 2) do not announce the aggregate (internally (see schilller paper) > nor externally) > 3) acls on the edge that drop traffic destined to your ptp/loops addresses. > > complexity is going to cause you pain, it is going to cause you > problems and it is going to lengthen outages :( avoid complexity. agree. hence i am of the opinion that the class of configuration in the draft should be clearly labeled as dangerous and ill-advised. though you might be arguing for its use by masochists and isps who want to lose customers. :) randy From nobody Wed Mar 26 20:04:50 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83DED1A0421; Wed, 26 Mar 2014 18:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BotauIsvIN9Q; Wed, 26 Mar 2014 18:31:21 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) by ietfa.amsl.com (Postfix) with ESMTP id 510E81A041C; Wed, 26 Mar 2014 18:31:21 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id s7so2132716lbd.9 for ; Wed, 26 Mar 2014 18:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZRWA/vwIHAQek/6vQq8SJrj3/MVmLjvBMhjOgIjrRbI=; b=i/VBhiJ1mGas2N01hSlr2EJx7/Tmks93fEVUT6/49pE5grxNsGowCIXGjfWRoKLL0Y N/Y7N0qHqkPzv903+akul+KzHOUDtTyGRiO48ZXHf3/qQceZHpFPoo5Kcw8fa3znXo2Q yaMlVS5FSxWZenRYHrmMWNCVzp9fbNtngpGSZn/TVul2XYA+wtZwPgQsi6m8w5eAxkWz Dk2DYgtTzOEuF/j4JH+lSGFu8g2qH1pOGZ5VBDONAkwyLXQ2LjPAc48pjvBa3Vaznbk3 lH69m78p1FFi3SDEEYxw+oLPiAdbXFuGhR9xfHMUwaZEsmI//eKyH1SEkc3aKUQNk5yi KS4A== MIME-Version: 1.0 X-Received: by 10.112.126.7 with SMTP id mu7mr15407194lbb.17.1395883879097; Wed, 26 Mar 2014 18:31:19 -0700 (PDT) Received: by 10.152.45.196 with HTTP; Wed, 26 Mar 2014 18:31:19 -0700 (PDT) In-Reply-To: References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> Date: Wed, 26 Mar 2014 21:31:19 -0400 Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/tc0eJQQ1cBiZDK-NHAntQc9g7ss X-Mailman-Approved-At: Wed, 26 Mar 2014 20:04:43 -0700 Cc: The IESG , opsec wg mailing list , Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 01:31:23 -0000 On Wed, Mar 26, 2014 at 5:54 PM, Randy Bush wrote: >> unless you can always be assured of testing from the device which is >> having problems. >> >> You could imagine an NMS/tool-set which knows: "Login to device before testing!" >> This also doesn't work of routing protocols for the device fail... > > i am in the noc 20 router hops away. so the code has to go hop by hop, > logging in to every router en route. the sec folk will love that. you > should talk to your sec folk. oh, you are your sec folk. So, I was presuming that the LLA was ONLY for the ptp links, and that loopbacks would still be standard old addresses like today. If the above is the case (my presumption) then you have access to the local-lo0 equivalent as along as your IGP is healthy, and you're ok. Of course, as soon as you pooch your IGP you're sunk :( I'm, again, not arguing FOR this configuration, just saying you could make it work, at a price of longer outages (most likely) and more (much MUCH more) complexity in your operations. I don't see what LLA gets you that: 1) put all your ptp/loops into 1 aggregate 2) do not announce the aggregate (internally (see schilller paper) nor externally) 3) acls on the edge that drop traffic destined to your ptp/loops addresses. complexity is going to cause you pain, it is going to cause you problems and it is going to lengthen outages :( avoid complexity. -chris From nobody Wed Mar 26 20:04:52 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26F21A0275; Wed, 26 Mar 2014 18:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2BJmhQApFZj; Wed, 26 Mar 2014 18:39:55 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 06C4C1A0012; Wed, 26 Mar 2014 18:39:54 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id y1so2121253lam.34 for ; Wed, 26 Mar 2014 18:39:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qz9QcR01R0OQQzwupJdFBYkwV6QSzLxFGjAxzhLfV1E=; b=Ex6eKAqIn0hX0Tn+PF8eLQKkVr1e9Y4gW3Cq5vCogAIsk2qAp0svKoe8ED/u4LWHTa fdLtfA1gVcDW8dcIxPrkBGZ32DahCQosI8+z5TQ0NOQOvjNZjuFbNSTTQ3C4FaTk6Vk/ HRCzMNQyq/PoOGgZOJ3Fk5nY4d5tJSqXFO8/UFSDzecIBEfsrXJ7wkc38SqriuTainI/ TK1tgBOEK2dmxIA5bmzrEjnd59D93amckN9L02vWBswnJVG9oTd9oxKWVh7IYTIYqXpB I+t3Tk4dEVLL7Dh0BuvyKiezPwDafKAUO/lemjuUQmPTZwWDm+2zgJPEU1DPE5kBD+UD mwtw== MIME-Version: 1.0 X-Received: by 10.112.47.3 with SMTP id z3mr348270lbm.34.1395884392816; Wed, 26 Mar 2014 18:39:52 -0700 (PDT) Received: by 10.152.45.196 with HTTP; Wed, 26 Mar 2014 18:39:52 -0700 (PDT) In-Reply-To: References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> Date: Wed, 26 Mar 2014 21:39:52 -0400 Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/b7n2p7BO1IYGFQx6d7aunTDygtg X-Mailman-Approved-At: Wed, 26 Mar 2014 20:04:43 -0700 Cc: The IESG , opsec wg mailing list , Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 01:39:57 -0000 On Wed, Mar 26, 2014 at 9:34 PM, Randy Bush wrote: >> I'm, again, not arguing FOR this configuration, just saying you could >> make it work, at a price of longer outages (most likely) and more >> (much MUCH more) complexity in your operations. I don't see what LLA >> gets you that: >> 1) put all your ptp/loops into 1 aggregate >> 2) do not announce the aggregate (internally (see schilller paper) >> nor externally) >> 3) acls on the edge that drop traffic destined to your ptp/loops addresses. >> >> complexity is going to cause you pain, it is going to cause you >> problems and it is going to lengthen outages :( avoid complexity. > > agree. hence i am of the opinion that the class of configuration in the > draft should be clearly labeled as dangerous and ill-advised. sure, a clear warning that: "Doing this is loading the double-barrel and aiming it clearly at your thigh!" seems ok to me. > though you might be arguing for its use by masochists and isps who want > to lose customers. :) "I encourage my competitors to do this..." -- -chris From nobody Wed Mar 26 20:27:01 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543371A043E; Wed, 26 Mar 2014 20:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfUG8b8hSI6p; Wed, 26 Mar 2014 20:26:58 -0700 (PDT) Received: from mx05.mykolab.com (mx01.mykolab.com [95.128.36.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147931A043C; Wed, 26 Mar 2014 20:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at kolabsys.net Sender: fergdawgster@mykolab.com Message-ID: <53339A75.20507@mykolab.com> Date: Wed, 26 Mar 2014 20:26:45 -0700 From: Paul Ferguson Organization: Clowns R. Mofos To: Christopher Morrow , Randy Bush References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/qCE7QH6qJ_fZlPquVs51Sm5iIXg Cc: opsec wg mailing list , The IESG , Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 03:27:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 3/26/2014 6:39 PM, Christopher Morrow wrote: > "I encourage my competitors to do this..." -- curmudgeon> It's funny how we all start to agree on a lot of things after a lot of years. :-) - - ferg - -- Paul Ferguson VP Threat Intelligence, IID PGP Public Key ID: 0x54DC85B2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMzmnUACgkQKJasdVTchbL+yQEAuu7Xi6jrjAFhXCyu92qahyWn o6sr3QCrNNT9wjW6F3ABAI5MaL+N8FZ/XX9+df484gKwzshOiaVsYZigsMyiyTTF =9zP2 -----END PGP SIGNATURE----- From nobody Thu Mar 27 00:13:59 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40ED81A01F6; Thu, 27 Mar 2014 00:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.561 X-Spam-Level: X-Spam-Status: No, score=-1.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FT0S3et35zD; Thu, 27 Mar 2014 00:11:07 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 184F61A0464; Thu, 27 Mar 2014 00:10:41 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 6BD34A5; Thu, 27 Mar 2014 08:10:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id DEF9AA3; Thu, 27 Mar 2014 08:10:36 +0100 (CET) Date: Thu, 27 Mar 2014 08:10:36 +0100 (CET) From: Mikael Abrahamsson To: Randy Bush In-Reply-To: Message-ID: References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/PhntJR6NerExyQD5ieShHmJIcNk Cc: opsec@ietf.org, Ted Lemon , The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 07:11:16 -0000 X-List-Received-Date: Thu, 27 Mar 2014 07:11:16 -0000 X-List-Received-Date: Thu, 27 Mar 2014 07:11:16 -0000 On Thu, 27 Mar 2014, Randy Bush wrote: > what is missing is "therefore all monitoring, diagnostic, management, > ... tools will not work. you will be unable to maintain your network. Since the loopback address still works to poll SNMP from, ssh to, etc, I don't agree with your statement. You have to use extra special care if you want to number using LL, but stating that it *won't work at all* isn't correct in my book. There are people who number P-T-P links using "unnumbered" between CE and PE today. This works for them. You just have to know the caveats, which is what the documents tries to describe. If there are caveats not listed, do tell and let's include them. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Thu Mar 27 07:42:33 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231271A06B2; Thu, 27 Mar 2014 07:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rx0V5IHcwSIt; Thu, 27 Mar 2014 07:42:25 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 49A891A02DB; Thu, 27 Mar 2014 07:42:25 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id rl12so3486025iec.22 for ; Thu, 27 Mar 2014 07:42:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d5neYcZLsjHs61BXyzxt/qN/PZXvtlApUwIH7uYIw+k=; b=IJcKspeN8ZIg+9GhFwA6+bgaVQ6/linm7cP4+lc23nf7IFT43KT4wxO6kZ/XZXR55A /O1vA1u7wih7GMGTnqZ7JYROVDOyVzbP7mAgxKJpnbpCIK89gRtZIyxHfEvU+H2jbSQi fB5l+lmuN38GpI9VmeoEEOIRRlsveo7iyqzTS8FJG8ihLeOgNMZK3MTPmgKvixp6MkMD br8QcgvtAOLJ8yKJQhn+8P1Xi+GXxrzQvih82AOjGCdOVlwPZ7ISEP/5+U49iI8yKpIh qTcf89l6oQofbmopplSyl1SDtil8zTkJcN1eKZT18KDtAysdqRsvyq/NDucbHroTSjeE l7uw== MIME-Version: 1.0 X-Received: by 10.50.92.102 with SMTP id cl6mr4879079igb.44.1395931343441; Thu, 27 Mar 2014 07:42:23 -0700 (PDT) Received: by 10.64.11.233 with HTTP; Thu, 27 Mar 2014 07:42:23 -0700 (PDT) In-Reply-To: References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> Date: Thu, 27 Mar 2014 10:42:23 -0400 Message-ID: From: Lee To: Mikael Abrahamsson Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/1gEL2AZADAtMD9Df6Tslbm4wkeA Cc: opsec@ietf.org, Ted Lemon , The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 14:42:28 -0000 On 3/27/14, Mikael Abrahamsson wrote: > There are people who number P-T-P links using "unnumbered" between CE and > PE today. This works for them. You just have to know the caveats ... Is this a fair summary of the caveats mentioned earlier?[1] - not being able to specifically ping one particular interface from the management system - not having traceroute tell me on which exact path my packets are flowing - NMS/discovery limitations - attempting to understand a deployed topology - as soon as you pooch your IGP you're sunk - longer outages and more complexity in your operations. Personally, I think 'attempting to understand a deployed topology' is a bit understated. The ability to match up interfaces on different routers & do off-line analysis can be huge. Anyone that hasn't seen Managing IP Networks with Free Software https://www.nanog.org/meetings/abstract?id=785 should go look now. And to ratchet the level of hyperbole down a notch, enabling uRPF can lead to - not being able to specifically ping one particular interface from the management system - not having traceroute tell me on which exact path my packets are flowing - NMS/discovery limitations and yet enabling uRPF is generally considered A Good Idea. It's a trade-off; at work we have a requirement for either uRPF or an input access list on "user subnet" interfaces. I got lazy, enabled uRPF and had someone at my desk two days ago saying they couldn't ping the HSRP interface address. ^shrug^ the input access list is a pain to create and manual verification is so error-prone that you really have to have a program that looks at the config to verify correctness. The point being that I went with uRPF _knowing_ it was going to cause some small level of operational complexity/breakage (oh Noes!! I can't ping ...) because I thought the alternative was worse. Which is a very long intro to the section 2.3 caveats list should also include off-line analysis: using LLA interface addresses mean that you can not do an off-line analysis of the deployed topology or do consistency checks between interfaces on each side of a link. - as soon as you pooch your IGP you're sunk should be listed but darn if I can come up with the wording - longer outages and more complexity in your operations. I'm leaning towards "value judgement" and so shouldn't be listed as a caveat Lee [1] snippets I saved for generating the caveats summary list: If you go back, I have commented on that draft that we'll never ever go link-local-only, because the drawbacks of not being able to specifically ping one particular interface from the management system, and not having traceroute tell me on which exact path my packets are flowing are not acceptable. YMMV on this, of course. Gert Doering Let me be explicit for those who need it... Operating with only link-local addresses isolates the devices from management systems located in a NOC (i.e., not directly adjacent). A typical first-step diagnostic when something goes wrong is to ping the address of the suspect interface *from the NOC*. That can't be done if the pesky device only has a link-local address. Brian Haberman Well, not attempting to speak for Randy, but I'd like to see a more balanced introduction (it summarizes the benefits; it should not just defer the caveats to the body), and maybe some discussion on where it might be useful to deploy a network using lla-only (homenets or small meshy things? I can't think of any enterprise or carrier scenario where I would want to do this), and clearer statement that this may not be for everybody and is not a general BCP. And while the caveats hint at it, there's also an operational complexity burden that isn't called out - the ping and NMS/discovery limitations also apply to human operators troubleshooting faults and attempting to understand a deployed topology. LLDP and NDP add a layer of indirection in identifying what devices should be adjacent to a given interface, and only work when there is operational state available and links are up (whereas GUAs on interconnected devices can be compared by configuration alone, telling you what's supposed to be there). Erik Muller So, I was presuming that the LLA was ONLY for the ptp links, and that loopbacks would still be standard old addresses like today. If the above is the case (my presumption) then you have access to the local-lo0 equivalent as along as your IGP is healthy, and you're ok. Of course, as soon as you pooch your IGP you're sunk :( I'm, again, not arguing FOR this configuration, just saying you could make it work, at a price of longer outages (most likely) and more (much MUCH more) complexity in your operations. I don't see what LLA gets you that: 1) put all your ptp/loops into 1 aggregate 2) do not announce the aggregate (internally (see schilller paper) nor externally) 3) acls on the edge that drop traffic destined to your ptp/loops addresses. complexity is going to cause you pain, it is going to cause you problems and it is going to lengthen outages :( avoid complexity. -chris > what is missing is "therefore all monitoring, diagnostic, management, ... tools > will not work. you will be unable to maintain your network. Since the loopback address still works to poll SNMP from, ssh to, etc, I don't agree with your statement. You have to use extra special care if you want to number using LL, but stating that it *won't work at all* isn't correct in my book. There are people who number P-T-P links using "unnumbered" between CE and PE today. This works for them. You just have to know the caveats, which is what the documents tries to describe. If there are caveats not listed, do tell and let's include them. Mikael Abrahamsson From nobody Thu Mar 27 08:22:57 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DE61A0147; Thu, 27 Mar 2014 08:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICOckBV6ztaX; Thu, 27 Mar 2014 08:22:48 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id CA7FD1A0346; Thu, 27 Mar 2014 08:22:48 -0700 (PDT) Received: from mb-aye.local ([173.247.205.34]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s2RFMijB009318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Mar 2014 15:22:45 GMT (envelope-from joelja@bogus.com) Message-ID: <53344243.1060101@bogus.com> Date: Thu, 27 Mar 2014 08:22:43 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0 MIME-Version: 1.0 To: Christopher Morrow , Randy Bush References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="07voe18jS0BxK4qInB3DcMqMrPmQ6V4c4" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 27 Mar 2014 15:22:45 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/A1iYIR8TiJRJ27wtNTiZiVwSu0M Cc: opsec wg mailing list , The IESG , Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:22:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --07voe18jS0BxK4qInB3DcMqMrPmQ6V4c4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 3/26/14, 6:31 PM, Christopher Morrow wrote: > On Wed, Mar 26, 2014 at 5:54 PM, Randy Bush wrote: >>> unless you can always be assured of testing from the device which is >>> having problems. >>> >>> You could imagine an NMS/tool-set which knows: "Login to device befor= e testing!" >>> This also doesn't work of routing protocols for the device fail... >> >> i am in the noc 20 router hops away. so the code has to go hop by hop= , >> logging in to every router en route. the sec folk will love that. yo= u >> should talk to your sec folk. oh, you are your sec folk. >=20 > So, I was presuming that the LLA was ONLY for the ptp links, and that > loopbacks would still be standard old addresses like today. >=20 > If the above is the case (my presumption) then you have access to the > local-lo0 equivalent as along as your IGP is healthy, and you're ok. > Of course, as soon as you pooch your IGP you're sunk :( >=20 > I'm, again, not arguing FOR this configuration, just saying you could > make it work, at a price of longer outages (most likely) and more > (much MUCH more) complexity in your operations. I don't see what LLA > gets you that: > 1) put all your ptp/loops into 1 aggregate > 2) do not announce the aggregate (internally (see schilller paper) > nor externally) > 3) acls on the edge that drop traffic destined to your ptp/loops addr= esses. Having had the opportunity to do this, for better or worse several times that's basically what I've done, drop traffic bound for the interior infrastructure aggregate via ingress acls. I think when were were discussing this in the w.g. that it has the potential to make things such as recursive next-hop calculation much harder since using link-local-scope addresses that aren't on-link for you would seem problematic. maybe using the loopback is an acceptable alterntive for some applications but you loose access to some tools this = way > complexity is going to cause you pain, it is going to cause you > problems and it is going to lengthen outages :( avoid complexity. >=20 > -chris >=20 --07voe18jS0BxK4qInB3DcMqMrPmQ6V4c4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM0QkMACgkQ8AA1q7Z/VrIXEQCfUahyoQfi/WuMIqMT90npjJbm FPQAnRaOttE2ATuz8IuQCRXSW1olD3dL =gCMr -----END PGP SIGNATURE----- --07voe18jS0BxK4qInB3DcMqMrPmQ6V4c4-- From nobody Thu Mar 27 08:29:09 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7461A00FD; Thu, 27 Mar 2014 08:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0k_e8hveDJaF; Thu, 27 Mar 2014 08:29:06 -0700 (PDT) Received: from mail-ee0-x236.google.com (mail-ee0-x236.google.com [IPv6:2a00:1450:4013:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id ECEC91A0067; Thu, 27 Mar 2014 08:29:05 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id d49so3006588eek.41 for ; Thu, 27 Mar 2014 08:29:03 -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:thread-index :content-language; bh=JkupVF6PLgvGUiTj2Ve1HuZa5doQ+hSAbVsT57FjxO4=; b=uCgb4jWeGvNXukd+tbVgDxlVepdRPLju9OGvy34PsG+rRu6114gu3fyS6cAgnm76dy XZegZks89xqt9hy8s0E+JyvkHhcWYH2favy+0BiRv+Rjo452sC8zfW2zboERxbzq/tpk 9XloO6SI+2YHneUDUBvtdVqPD9FbPWErO9CdNs1fjjejVnTuy3gQSuGnCoEAyjCDH7Uo KgMEYrKEGrdK/QPZLNDDJgBtMhaH1YRwGHmsTJ9vR8gqWOMANiExYi3G8uO6OxsLh1sj PkuIM3xEpzc2nf6VzOOM2vjItrO3HoV+NbqH2DB20xrQ6dC6aB5YA237iq3Gp9K5j72C lSvw== X-Received: by 10.14.110.199 with SMTP id u47mr1387006eeg.74.1395934143704; Thu, 27 Mar 2014 08:29:03 -0700 (PDT) Received: from PC120029283 (BSN-61-119-189.dial-up.dsl.siol.net. [86.61.119.189]) by mx.google.com with ESMTPSA id x45sm5039495eeu.23.2014.03.27.08.29.02 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Mar 2014 08:29:02 -0700 (PDT) From: "Ivan Pepelnjak" To: "'joel jaeggli'" , "'Christopher Morrow'" , "'Randy Bush'" References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> <53344243.1060101@bogus.com> In-Reply-To: <53344243.1060101@bogus.com> Date: Thu, 27 Mar 2014 16:29:01 +0100 Message-ID: <00c001cf49d1$485fbca0$d91f35e0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQG6BlameiIltoh+WJywFMLMwpOFGgEGVbvsAePiy2AB5T79agFlB65sAiLDKwQB7XrArgMX6rm7Aa4xsVEBqOAuUwH/UOoBAQw361IBZ13E/5p2YDiQ Content-Language: sl Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/tXl-rDwHdW-juS7lIxLvGYoysVg Cc: 'opsec wg mailing list' , 'The IESG' , 'Ted Lemon' Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:29:08 -0000 > On 3/26/14, 6:31 PM, Christopher Morrow wrote: [...] > I think when were were discussing this in the w.g. that it has the = potential to > make things such as recursive next-hop calculation much harder since = using > link-local-scope addresses that aren't on-link for you would seem = problematic. I wonder what happens when you run BGP over LLA and use "neighbor = next-hop-self" (which many people do on AS edge routers) or have no next = hop in local BGP table (due to aggregation or static route to null 0) = ... Regardless of all the "benefits" I still think this is a bad idea. Ivan From nobody Thu Mar 27 08:35:38 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873D71A00FB; Thu, 27 Mar 2014 08:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.475 X-Spam-Level: X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_8Hl8eClzPK; Thu, 27 Mar 2014 08:35:27 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE501A0067; Thu, 27 Mar 2014 08:35:26 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,743,1389762000"; d="scan'208";a="252260015" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 27 Mar 2014 11:34:24 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.79]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Thu, 27 Mar 2014 11:35:24 -0400 From: "George, Wes" To: Christopher Morrow , Ted Lemon Date: Thu, 27 Mar 2014 11:35:23 -0400 Thread-Topic: Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC Thread-Index: Ac9J0it4g4ypupX+RKK9IVT6u5ttqg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/iVR-rNDiKyQGdErXEy-u6AKIvfE Cc: opsec wg mailing list , The IESG , "ietf@ietf.org" Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 15:35:29 -0000 SeKAmWQgbGlrZSB0byBhZGQgYW5vdGhlciB2b2ljZSBzdXBwb3J0aW5nIHRoZSBzdWdnZXN0aW9u IHRoYXQgdGhpcyBkb2N1bWVudA0KaW5jbHVkZSBhbiBJRVNHIHdhcm5pbmcgdGhhdCBpdCBpcyBu b3QgYW4gSUVURi1yZWNvbW1lbmRlZCB0aGluZyB0byBkbywgaW4NCm9yZGVyIHRvIHJlZHVjZSBw b3NzaWJpbGl0eSBvZiBjb25mdXNpb24gYWJvdXQgd2hldGhlciBvciBub3QgSUVURg0KY29uc2Vu c3VzIGluIHRoaXMgY2FzZSBpcyDigJx5ZXMgdGhpcyBpcyBhIHRoaW5nIGNvbnNlbnRpbmcgYWR1 bHRzIGNhbiBkbyBvbg0KdGhlIHByaXZhY3kgb2YgdGhlaXIgb3duIG5ldHdvcmvigJ0gdnMgYSBy aW5naW5nIGVuZG9yc2VtZW50IHRoYXQg4oCcSUVURg0KdGhpbmtzIHRoYXQgdGhpcyBpcyBhIHRo aW5nIHRoYXQgeW91IFNIT1VMRCBkbyBvbiB5b3VyIG5ldHdvcmvigJ0uIEV2ZW4NCnRob3VnaCB0 aGUgZG9jdW1lbnQgaXMgbm90IGEgQkNQLCB0aGUgZG9jdW1lbnTigJlzIHN0YXR1cyBhcyBhbg0K aW5mb3JtYXRpb25hbCBjb25zZW5zdXMgUkZDIGNhcnJpZXMgd2VpZ2h0IGFtb25nIHRob3NlIGxv b2tpbmcgZm9yDQpndWlkYW5jZSBvbiB0aGUgbnV0cyBhbmQgYm9sdHMgb2YgaW1wbGVtZW50aW5n IElQdjYgb24gYSBuZXR3b3JrLg0KDQpUaGUgYXV0aG9ycyBoYXZlIGRvbmUgYSBnb29kIGpvYiBv ZiByZXNwb25kaW5nIHRvIHRoaXMgY29uY2VybiBieQ0KZWxpbWluYXRpbmcgdGhlIGxhbmd1YWdl IGNvbnRhaW5lZCBpbiBlYXJsaWVyIHZlcnNpb25zIG9mIHRoZSBkb2MgdGhhdA0KcmVhZCBsaWtl IGEgcmVjb21tZW5kYXRpb24vZW5kb3JzZW1lbnQsIGJ1dCBJ4oCZZCBzdGlsbCByYXRoZXIgc2Vl IHRoaXMgYXMNCmFuIGluZGl2aWR1YWwgZG9jdW1lbnQsIGFuZCBmYWlsaW5nIHRoYXQsIHN1aXRh Ymx5IHByZWZhY2VkIHdpdGggYSB3YXJuaW5nLg0KDQpTb21lIHNwZWNpZmljIGNvbW1lbnRzIHRv IGhlbHAgZXhwbGFpbiB3aHkg4oCcYmFkIGlkZWHigJ0ga2VlcHMgZ2V0dGluZyB0aHJvd24NCmFy b3VuZDoNCg0KDQpPbiAzLzI2LzE0LCA5OjMxIFBNLCAiQ2hyaXN0b3BoZXIgTW9ycm93IiA8Y2hy aXN0b3BoZXIubW9ycm93QGdtYWlsLmNvbT4NCndyb3RlOg0KPlNvLCBJIHdhcyBwcmVzdW1pbmcg dGhhdCB0aGUgTExBIHdhcyBPTkxZIGZvciB0aGUgcHRwIGxpbmtzLCBhbmQgdGhhdA0KPmxvb3Bi YWNrcyB3b3VsZCBzdGlsbCBiZSBzdGFuZGFyZCBvbGQgYWRkcmVzc2VzIGxpa2UgdG9kYXkuDQo+ DQo+SWYgdGhlIGFib3ZlIGlzIHRoZSBjYXNlIChteSBwcmVzdW1wdGlvbikgdGhlbiB5b3UgaGF2 ZSBhY2Nlc3MgdG8gdGhlDQo+bG9jYWwtbG8wIGVxdWl2YWxlbnQgYXMgYWxvbmcgYXMgeW91ciBJ R1AgaXMgaGVhbHRoeSwgYW5kIHlvdSdyZSBvay4NCg0KQ29udmVuaWVudGx5LCBJ4oCZdmUgcmFp c2VkIHRoaXMgYmVmb3JlIFsxXQ0KIkRpYWdub3N0aWMgdG9vbHMgbGlrZSBwaW5ncyBhbmQgdHJh Y2VzLCBhcyB3ZWxsIGFzIG1vcmUgaW1wb3J0YW50IHRoaW5ncw0KbGlrZSBQTVRVRCBhcmUgYnJp dHRsZSBlbm91Z2ggd2l0aG91dCBhZHZvY2F0aW5nIHRoaXMgcHJhY3RpY2UgZm9yDQpxdWVzdGlv bmFibGUgYmVuZWZpdC4gWWVzLCB5b3UgY2FuIGNvbmZpZ3VyZSBhIHJvdXRlciB0byByZXNwb25k IHRvIElDTVANCnZpYSBhIHJvdXRhYmxlIGxvb3BiYWNrIGFkZHJlc3MuIEhvd2V2ZXIsICByZWx5 aW5nIG9uIHN1Y2ggY29uZmlndXJhdGlvbg0KYmVpbmcgcHJvcGVybHkgaW1wbGVtZW50ZWQsIGxl dCBhbG9uZSBhcHBsaWVkIHBlcnZhc2l2ZWx5IGFuZCBjb25zaXN0ZW50bHkNCnRvIG1ha2UgY3Jp dGljYWwgYml0cyBvZiBpbmZyYXN0cnVjdHVyZSB3b3JrIHNlZW1zIHJpc2t5LiBOb3cgSSBoYXZl IHRvDQphc2sgd2hldGhlciB0aGUgdHJhY2UgZmFpbGVkIGJlY2F1c2UgdGhlIHJvdXRlciBpc24n dCByZXNwb25kaW5nIHdpdGggdGhlDQpyaWdodCBpbnRlcmZhY2UsIG9yIGJlY2F1c2Ugc29tZXRo aW5nJ3MgYWN0dWFsbHkgYnJva2VuLiBJIGFsc28gaGF2ZSBhDQpodW5jaCB0aGF0IHRoaXMgd291 bGQgZXhwb3NlIGEgd2hvbGUgbmV3IGNyb3Agb2Ygcm91dGluZyBwcm90b2NvbCBuZXh0LWhvcA0K YnVncyBhbmQgYXNzb3J0ZWQgd2VpcmRuZXNzIGJhc2VkIG9uIHdoYXQgKGZsYXdlZCkgYXNzdW1w dGlvbnMgcm91dGVyDQp2ZW5kb3JzIG1hZGUgYWJvdXQgaW50ZXJmYWNlIGFkZHJlc3NpbmcgYW5k IHJlYWNoYWJpbGl0eSB3aGVuDQppbXBsZW1lbnRpbmcuIg0KDQo+DQo+Y29tcGxleGl0eSBpcyBn b2luZyB0byBjYXVzZSB5b3UgcGFpbiwgaXQgaXMgZ29pbmcgdG8gY2F1c2UgeW91DQo+cHJvYmxl bXMgYW5kIGl0IGlzIGdvaW5nIHRvIGxlbmd0aGVuIG91dGFnZXMgOiggYXZvaWQgY29tcGxleGl0 eS4NCisxDQoNCkEgZnVydGhlciBxdW90ZSBmcm9tIFsxXSByZWdhcmRpbmcgb3BlcmF0aW9uYWwg Y29uc2lkZXJhdGlvbnMgdGhhdCB0aGUNCmRvY3VtZW50IGhhcyBub3QsIElNTyBzdWl0YWJseSBh ZGRyZXNzZWQ6DQoiTExBIGhhcyBvdGhlciBpc3N1ZXM6DQotIGRpYWdub3N0aWMgcGluZ3MgYWNy b3NzIGNvbm5lY3RlZCBpbnRlcmZhY2VzIGFyZSBoYXJkZXIgdG8gY29tcGxldGUgLQ0KaW5zdGVh ZCBvZiBzaW1wbHkgdHlwaW5nIHBpbmcgW2FkZHJlc3NdLCBvbmUgbXVzdCBub3cgc3BlY2lmeSB0 aGUgZXhpdA0KaW50ZXJmYWNlLCBlZmZlY3RpdmVseSBkb3VibGluZyB0aGUgY29tbWFuZHMgcmVx dWlyZWQuDQotIGRpYWdub3N0aWMgdHJhY2Vyb3V0ZXMgYXJlIHNpbWlsYXJseSBoYXJkZXIgYmVj YXVzZSBvbmUgbXVzdCBzcGVjaWZ5IGENCnJvdXRhYmxlIHNvdXJjZSBpbnRlcmZhY2UgYW5kIGRl c3RpbmF0aW9uLg0KLSBpbiBsYXJnZSBuZXR3b3JrcywgbW9zdCBjb25uZWN0ZWQgaW50ZXJmYWNl cyBhcmUgbnVtYmVyZWQgdXNpbmcgYQ0Kc3RhbmRhcmQgbnVtYmVyaW5nIHNjaGVtZSBzdWNoIHRo YXQgb25lIGNhbiBkZXJpdmUgdGhlIGFkZHJlc3Mgb2YgdGhlDQpyZW1vdGUgc2lkZSBieSBzaW1w bHkgYWRkaW5nIG9yIHN1YnRyYWN0aW5nIDEgZnJvbSB0aGUgbG9jYWwgSVAgYWRkcmVzcy4NClBp bmdzIHRvIHRoZSByZW1vdGUgc2lkZSB3aGVuIGR5bmFtaWMgTExBcyBhcmUgdXNlZCByZXF1aXJl IGRldGVybWluaW5nDQp0aGUgYWRkcmVzcyB0byBiZSBwaW5nZWQsIGVpdGhlciB2aWEgYSBzaG93 IGludGVyZmFjZSBvbiB0aGUgcmVtb3RlIHNpZGUsDQpvciBhIHNob3cgaXB2NiBuZWlnaGJvciBv biB0aGUgbG9jYWwgc2lkZSwgYW5kIG1heSBiZSBtb3JlIHByb25lIHRvDQpvcGVyYXRvci1pbmR1 Y2VkIGZhaWx1cmUgZHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhlIGFkZHJlc3NlcyBhcmUgbm90DQpv YnZpb3VzbHkgc2ltaWxhciB0byBvbmUgYW5vdGhlci4NCi0gYmVjYXVzZSBkeW5hbWljIGFkZHJl c3NlcyBhcmUgbm90IHByZXNlbnQgaW4gdGhlIGNvbmZpZ3VyYXRpb24sIGl0IGlzDQppbXBvc3Np YmxlIHRvIHNlYXJjaCBmb3IgdGhlbSB0byBkZXRlcm1pbmUgd2hlcmUgYSBnaXZlbiBhZGRyZXNz IG1heSBiZSBpZg0KaXQgc2hvd3MgdXAgaW4gZGlhZ25vc3RpYyBpbmZvcm1hdGlvbiAocGFja2V0 IGNhcHR1cmVzLCB0cmFjZXMsIHJvdXRpbmcNCnVwZGF0ZXMsIGV0YykuIFN0YXRpY2FsbHktYXNz aWduZWQgYWRkcmVzc2VzIHNob3cgdXAgaW4gY29uZmlndXJhdGlvbiwNCm1lYW5pbmcgdGhhdCBz aW1wbGUgdG9vbHMgbGlrZSBncmVwcGluZyBhIHJhbmNpZCBjb25maWcgcmVwb3NpdG9yeSBjYW4N CmZpbmQgdGhlIHJvdXRlciBvbiB3aGljaCB0aGF0IGFkZHJlc3MgaXMgbG9jYXRlZC4iDQoNClRo YW5rcywNCg0KV2VzIEdlb3JnZQ0KDQpbMV0gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL29wc2VjL2N1cnJlbnQvbXNnMDEyNTguaHRtbA0KDQoNCkFueXRoaW5nIGJlbG93IHRo aXMgbGluZSBoYXMgYmVlbiBhZGRlZCBieSBteSBjb21wYW554oCZcyBtYWlsIHNlcnZlciwgSQ0K aGF2ZSBubyBjb250cm9sIG92ZXIgaXQuDQotLS0tLS0tLS0tLQ0KDQoNClRoaXMgRS1tYWlsIGFu ZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHBy b3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWws IG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4g VGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlm aWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0 aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMg dG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVs LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdp bmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Lg0K From nobody Thu Mar 27 11:46:41 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243101A01D1; Thu, 27 Mar 2014 11:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajLwm8mrtKgj; Thu, 27 Mar 2014 11:24:32 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 43B211A0165; Thu, 27 Mar 2014 11:24:32 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id s7so2964812lbd.29 for ; Thu, 27 Mar 2014 11:24:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=APauK6C75jFwa2fNcFYE8VJouBDaC0QUurEuF0uQFJU=; b=ornZK+dDXs8cPF3JnBEF8PYj9wf6DYzmIsTipqlQ94Eoa4v253FtcVcwG7vIRuolq2 7r2mRX5cj+5BtMLbe4usOu4h/sXfk/oSmRTJxvoeRrUl8f8nhCH8Rtw54bt1gjp4R8mY /5v5uGTh4qkq/9uLbjBjxowa2n498+wk0fgRmzxyLOg/scFzxatpL6FsVgxjVY9FxRdQ KzpXIN92/22//z219je/DCp0qH7yj84UHDaEqEuz+oUP1vM6J1K4LPOEYFwO4HCiKylt +BtD2BGLjICKYmfVbuE+dPM7UJ07Iuu5GCwYIRd6wfcFSZCteZ/xj8JOKqtAFhdBNnw4 E+Pg== MIME-Version: 1.0 X-Received: by 10.152.170.202 with SMTP id ao10mr1877116lac.46.1395944669824; Thu, 27 Mar 2014 11:24:29 -0700 (PDT) Received: by 10.152.45.196 with HTTP; Thu, 27 Mar 2014 11:24:29 -0700 (PDT) In-Reply-To: <53344243.1060101@bogus.com> References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> <53344243.1060101@bogus.com> Date: Thu, 27 Mar 2014 14:24:29 -0400 Message-ID: From: Christopher Morrow To: joel jaeggli Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/MP6n_oEpaikEv3JucldE4rVkeBM X-Mailman-Approved-At: Thu, 27 Mar 2014 11:46:38 -0700 Cc: Randy Bush , opsec wg mailing list , The IESG , Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 18:24:34 -0000 On Thu, Mar 27, 2014 at 11:22 AM, joel jaeggli wrote: > I think when were were discussing this in the w.g. that it has the > potential to make things such as recursive next-hop calculation much yup, certainly... you probably have to think long and hard about any standard advice from vendors/third-parties about configuration optimizations ;( > harder since using link-local-scope addresses that aren't on-link for > you would seem problematic. maybe using the loopback is an acceptable > alterntive for some applications but you loose access to some tools this way see my comment about complexity... oh, included below, how nice of you :) >> complexity is going to cause you pain, it is going to cause you >> problems and it is going to lengthen outages :( avoid complexity. -chris From nobody Thu Mar 27 14:01:32 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D361A06C7 for ; Thu, 27 Mar 2014 14:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huHf59ayf2uB for ; Thu, 27 Mar 2014 14:01:28 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 97B271A06B2 for ; Thu, 27 Mar 2014 14:01:27 -0700 (PDT) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id D3BDB60657 for ; Thu, 27 Mar 2014 22:01:24 +0100 (CET) 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 8CDFE6049E for ; Thu, 27 Mar 2014 22:01:24 +0100 (CET) Received: (qmail 39677 invoked by uid 1007); 27 Mar 2014 22:01:24 +0100 Date: Thu, 27 Mar 2014 22:01:24 +0100 From: Gert Doering To: Lee Message-ID: <20140327210124.GE43641@Space.Net> References: <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> 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) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/xDal-bwAwHQyHd6iiOiLnQeSTGo Cc: The IESG , opsec@ietf.org, Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 21:01:31 -0000 Hi, On Thu, Mar 27, 2014 at 10:42:23AM -0400, Lee wrote: > And to ratchet the level of hyperbole down a notch, enabling uRPF can lead to > - not being able to specifically ping one particular interface from > the management system > - not having traceroute tell me on which exact path my packets are flowing > - NMS/discovery limitations > and yet enabling uRPF is generally considered A Good Idea. Actually, enabling uRPF on core-to-core interfaces is considered a significantly stupid idea. You enable uRPF towards your customers, and loose(!) uRPF towards peers/upstreams for BGP-RTBH. None of these will impair traceroute or NMS/discovery. 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 (0)89/32356-444 USt-IdNr.: DE813185279 From nobody Thu Mar 27 15:03:21 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 411AB1A03D1; Thu, 27 Mar 2014 15:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjVpS0g6yx56; Thu, 27 Mar 2014 15:02:44 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id AA0461A03DA; Thu, 27 Mar 2014 15:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1395957763; x=1427493763; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=suT63tJHCw8T2OOtWiSauZhanomeI2U3ZWKa6WQCigQ=; b=O/1vjc441lxdyLk74J1fxQ4vZRsYwcUaoo11u012NaWUSPqabZAf0Ful r3Sby9/z58MBLZKqsNYf6HdMrV+7ykxLLzBgg7USuBlbn5AJ1yHkhn/cn Ig4mOsMpkwcpxGeWQJXmQwO0Vg8GpE3+B6CNpI7I+97ohQBJFaJRzQiHn I=; X-IronPort-AV: E=McAfee;i="5400,1158,7390"; a="116086924" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by wolverine02.qualcomm.com with ESMTP; 27 Mar 2014 15:02:42 -0700 X-IronPort-AV: E=Sophos;i="4.97,745,1389772800"; d="scan'208";a="29151172" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Mar 2014 15:02:41 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 15:02:41 -0700 Message-ID: <53349FFB.7050108@qti.qualcomm.com> Date: Thu, 27 Mar 2014 17:02:35 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "George, Wes" References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/2cEJ_dg1-Czoh3loPE0D1-agL-Y Cc: Christopher Morrow , opsec wg mailing list , "ietf@ietf.org" , Ted Lemon , The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 22:02:51 -0000 On 3/27/14 10:35 AM, George, Wes wrote: > I’d like to add another voice supporting the suggestion that this document > include an IESG warning that it is not an IETF-recommended thing to do, in > order to reduce possibility of confusion about whether or not IETF > consensus in this case is “yes this is a thing consenting adults can do on > the privacy of their own network” vs a ringing endorsement that “IETF > thinks that this is a thing that you SHOULD do on your network”. I'm speaking as only 1/15 of the IESG, but putting IESG statements on the tops of documents is a very icky business, *especially* on IETF consensus documents. I'd much rather tell the WG, "There's a bunch of IETF folks who came out during Last Call and said you have to fix this, so go fix it" than try to get the IESG into the business of writing text. If there's not IETF-wide rough consensus for the document as-is, fix it or ditch it. Telling the IESG to "approve it, but put in a note from on high saying why it's bogus" is....bogus. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Mar 27 15:13:28 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0B71A06F6; Thu, 27 Mar 2014 15:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pgMC0jQIjbz0; Thu, 27 Mar 2014 15:13:16 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AE3931A03D1; Thu, 27 Mar 2014 15:13:16 -0700 (PDT) Received: from mb-aye.local ([173.247.205.34]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s2RMDESH012650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Mar 2014 22:13:14 GMT (envelope-from joelja@bogus.com) Message-ID: <5334A278.7080108@bogus.com> Date: Thu, 27 Mar 2014 15:13:12 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0 MIME-Version: 1.0 To: Pete Resnick , "George, Wes" References: <53349FFB.7050108@qti.qualcomm.com> In-Reply-To: <53349FFB.7050108@qti.qualcomm.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRD54Ie0jokGrUxPlrGdFHvUG8pFWwaP7" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 27 Mar 2014 22:13:14 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/6lmCOfPRwRI_1KuTr3l1Ks614R8 Cc: The IESG , Christopher Morrow , Ted Lemon , opsec wg mailing list , "ietf@ietf.org" Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 22:13:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TRD54Ie0jokGrUxPlrGdFHvUG8pFWwaP7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 3/27/14, 3:02 PM, Pete Resnick wrote: > On 3/27/14 10:35 AM, George, Wes wrote: >> I=92d like to add another voice supporting the suggestion that this >> document >> include an IESG warning that it is not an IETF-recommended thing to >> do, in >> order to reduce possibility of confusion about whether or not IETF >> consensus in this case is =93yes this is a thing consenting adults can= >> do on >> the privacy of their own network=94 vs a ringing endorsement that =93I= ETF >> thinks that this is a thing that you SHOULD do on your network=94. >=20 > I'm speaking as only 1/15 of the IESG, but putting IESG statements on > the tops of documents is a very icky business, *especially* on IETF > consensus documents. I'd much rather tell the WG, "There's a bunch of > IETF folks who came out during Last Call and said you have to fix this,= > so go fix it" than try to get the IESG into the business of writing > text. If there's not IETF-wide rough consensus for the document as-is, > fix it or ditch it. Telling the IESG to "approve it, but put in a note > from on high saying why it's bogus" is....bogus. So I think the issue, and I don't want to second guess the chairs here (unless asked, in which case it's my job), is that fundamentally if you don't like this approach there's no fixing it. It's just icky. So if you dislike it, but concede that it does work for some people then you're in my camp. I absolutely would not go to the wall over this approach even if I wouldn't employ it and find it to be more trouble then it's worth. There is evidence of successful deployments and a plausible rational for why people find it necessary. > pr >=20 --TRD54Ie0jokGrUxPlrGdFHvUG8pFWwaP7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM0onkACgkQ8AA1q7Z/VrLXIgCeJX273ITXaEr9ym/UmoDODFbY lTQAn3VlckvYfmXIQyBwo85gAKiOSCOQ =EHJf -----END PGP SIGNATURE----- --TRD54Ie0jokGrUxPlrGdFHvUG8pFWwaP7-- From nobody Thu Mar 27 15:55:31 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020DB1A0709; Thu, 27 Mar 2014 15:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BN8DSXetwiGW; Thu, 27 Mar 2014 15:55:24 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id 94E971A0707; Thu, 27 Mar 2014 15:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1395960923; x=1427496923; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=UIHx58U2MZuNNk9di1zlVJehNgZoE8AWdkD1pgqsM5I=; b=QBmUZpjlVfOGYO1Ot4eM9XaQktY66C/az16yc+rcdQuzU80i7ia14z7q +NS/3PSU5t9+AtuXkmNfif8a7lVv7RX/QpaKEJUYFk8eFtzF6AwehZTGD WES5Qt+uC4+LhxrbqzWP3BuyiQtk8tng16HQFRtGCb2KKWXJ1N4tXY5eC E=; X-IronPort-AV: E=McAfee;i="5400,1158,7390"; a="116094833" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine02.qualcomm.com with ESMTP; 27 Mar 2014 15:55:22 -0700 X-IronPort-AV: E=Sophos;i="4.97,745,1389772800"; d="scan'208";a="616267356" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 27 Mar 2014 15:55:22 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 15:55:21 -0700 Message-ID: <5334AC57.5050809@qti.qualcomm.com> Date: Thu, 27 Mar 2014 17:55:19 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: joel jaeggli References: <53349FFB.7050108@qti.qualcomm.com> <5334A278.7080108@bogus.com> In-Reply-To: <5334A278.7080108@bogus.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/uxHFe78iNti2eBSFyKX1S9rsPcU Cc: "ietf@ietf.org" , opsec wg mailing list , Christopher Morrow , The IESG , Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 22:55:26 -0000 On 3/27/14 5:13 PM, joel jaeggli wrote: > On 3/27/14, 3:02 PM, Pete Resnick wrote: > >> On 3/27/14 10:35 AM, George, Wes wrote: >> >>> I’d like to add another voice supporting the suggestion that this >>> document >>> include an IESG warning that it is not an IETF-recommended thing to >>> do, in >>> order to reduce possibility of confusion about whether or not IETF >>> consensus in this case is “yes this is a thing consenting adults can >>> do on >>> the privacy of their own network” vs a ringing endorsement that “IETF >>> thinks that this is a thing that you SHOULD do on your network”. >>> >> I'm speaking as only 1/15 of the IESG, but putting IESG statements on >> the tops of documents is a very icky business, *especially* on IETF >> consensus documents. I'd much rather tell the WG, "There's a bunch of >> IETF folks who came out during Last Call and said you have to fix this, >> so go fix it" than try to get the IESG into the business of writing >> text. If there's not IETF-wide rough consensus for the document as-is, >> fix it or ditch it. Telling the IESG to "approve it, but put in a note >> from on high saying why it's bogus" is....bogus. >> > So I think the issue, and I don't want to second guess the chairs here > (unless asked, in which case it's my job), is that fundamentally if you > don't like this approach there's no fixing it. It's just icky. > Oh, don't get me wrong. When I say "fix it", I don't mean that they necessarily need to fix the protocol the approach. I simply mean fix the document, which may amount to the WG getting sufficient text in to say, "This is only useful in X Y and Z circumstances and is otherwise a bad idea and you shouldn't do it." We are happy to publish all sorts of applicability statements that say, "This is stupid in all but these circumstances." I just don't want the IESG to have to write it up. The WG should make their document reflect what the community wants. > So if you dislike it, but concede that it does work for some people > then you're in my camp. I absolutely would not go to the wall over this > approach even if I wouldn't employ it and find it to be more trouble > then it's worth. There is evidence of successful deployments and a > plausible rational for why people find it necessary. Just in case that "you" was me: I am completely agnostic about this document; I'm just talking about what the community should be expecting of the IESG. If the community decides that this thing is useful to document for the segment of people who do want to do it, have at it. If not, not. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Thu Mar 27 15:57:45 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDB21A0274; Thu, 27 Mar 2014 15:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9ulVo22AveN; Thu, 27 Mar 2014 15:57:36 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) by ietfa.amsl.com (Postfix) with ESMTP id 09F881A024E; Thu, 27 Mar 2014 15:57:36 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.76) (envelope-from ) id 1WTJEr-0006gp-6o; Thu, 27 Mar 2014 22:57:33 +0000 Date: Fri, 28 Mar 2014 07:57:31 +0900 Message-ID: From: Randy Bush To: Pete Resnick In-Reply-To: <53349FFB.7050108@qti.qualcomm.com> References: <53349FFB.7050108@qti.qualcomm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/gtrBf6MZAqLaDL91Mi-X53Ygnuo Cc: opsec wg mailing list , IETF Disgust , The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 22:57:37 -0000 > putting IESG statements on the tops of documents is a very icky > business, *especially* on IETF consensus documents. I'd much rather > tell the WG, "There's a bunch of IETF folks who came out during Last > Call and said you have to fix this, so go fix it" than try to get the > IESG into the business of writing text. If there's not IETF-wide rough > consensus for the document as-is, fix it or ditch it. the iesg can sort out the process. i really don't care. i gave at the office (apologies fo ramerican idiom). what matters to me is that, if this document is published that it is clear to the reader that doing this is ill-advised. a deep dive into why it is ill-advised might be educational, but i see it as optional. randy From nobody Thu Mar 27 16:34:40 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 045491A03F4; Thu, 27 Mar 2014 16:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OCjYLWvk7_l; Thu, 27 Mar 2014 16:34:27 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 151021A03EE; Thu, 27 Mar 2014 16:34:27 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 37885C94A8; Thu, 27 Mar 2014 19:34:22 -0400 (EDT) Date: Thu, 27 Mar 2014 19:34:22 -0400 From: John Leslie To: Randy Bush Message-ID: <20140327233422.GD87785@verdi> References: <53349FFB.7050108@qti.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/4wEguaAibOVH3evO0YcHE_T010M Cc: The IESG , Pete Resnick , opsec wg mailing list , IETF Disgust Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 23:34:29 -0000 Randy Bush wrote: > [Pete Resnick wrote:] > >> putting IESG statements on the tops of documents is a very icky >> business, *especially* on IETF consensus documents. The IESG really doesn't have the spare cycles to go there. >> I'd much rather tell the WG, "There's a bunch of IETF folks who came >> out during Last Call and said you have to fix this, so go fix it" >> than try to get the IESG into the business of writing text. When the IESG tries that, a _very_ common outcome is for the document to come back on the agenda with the responsible AD reporting "The authors declined that offer." ... at which point the IESG admits it doesn't have the spare cycles to go further. >> If there's not IETF-wide rough consensus for the document as-is, fix >> it or ditch it. The sad truth is, the IESG no longer has the spare cycles to "Just say No." (I wish we'd find boilerplate to record such "limited" consensus.) > the iesg can sort out the process. i really don't care. i gave at the > office (apologies fo ramerican idiom). what matters to me is that, if > this document is published that it is clear to the reader that doing > this is ill-advised. a deep dive into why it is ill-advised might be > educational, but i see it as optional. I'm not sure the OPSEC WG has the cycles to go there, either :^( (FWIW, I'm with Randy on this being a bad idea; but I doubt that actual operators pay much attention to RFCs when looking for operational advice.) Bottom line: _I_ really don't have the cycles to go there. :^( -- John Leslie From nobody Thu Mar 27 16:46:31 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A6D1A0743; Thu, 27 Mar 2014 16:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUAyKK2FwhW7; Thu, 27 Mar 2014 16:46:18 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id F36011A072E; Thu, 27 Mar 2014 16:46:17 -0700 (PDT) Received: from mb-aye.local ([173.247.205.34]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s2RNkFZo013294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 27 Mar 2014 23:46:16 GMT (envelope-from joelja@bogus.com) Message-ID: <5334B847.6030205@bogus.com> Date: Thu, 27 Mar 2014 16:46:15 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0 MIME-Version: 1.0 To: Andrew Sullivan , John Leslie References: <53349FFB.7050108@qti.qualcomm.com> <20140327233422.GD87785@verdi> <20140327234136.GC51988@mx1.yitter.info> In-Reply-To: <20140327234136.GC51988@mx1.yitter.info> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ju9wvwH6XCACEIQV2iF3DW3MCETf5hJWv" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Thu, 27 Mar 2014 23:46:16 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/zELo1CloMmK1pUZBx_NYbrVRHCA Cc: Randy Bush , Pete Resnick , IETF Disgust , opsec wg mailing list , The IESG Subject: Re: [OPSEC] Saying no X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 23:46:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ju9wvwH6XCACEIQV2iF3DW3MCETf5hJWv Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 3/27/14, 4:41 PM, Andrew Sullivan wrote: > On Thu, Mar 27, 2014 at 07:34:22PM -0400, John Leslie wrote: >> >> The sad truth is, the IESG no longer has the spare cycles to "Just >> say No." responsible AD here. I take the IETF LC input with the gravitas that's appropriate. the IESG review occurs after the LC. > I was on the receiving end of an IESG that simply stalled a document > until the WG changed its approach, because of IETF concerns, so I > disagree with that claim. But if it is true, then we might as well > give up. If there's weak IETF consensus (with some strong objections) > to a document that comes from a WG and has strong consensus inside the > WG, the _only_ people who can say no are the IESG; and they must. > > Best regards, >=20 > A >=20 --ju9wvwH6XCACEIQV2iF3DW3MCETf5hJWv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM0uEcACgkQ8AA1q7Z/VrJ2twCeKveq8Lc01jIJy9t28CE/axco g0AAn2mZhtv11aavM7J2nbqiKOhAwnA1 =Lp+z -----END PGP SIGNATURE----- --ju9wvwH6XCACEIQV2iF3DW3MCETf5hJWv-- From nobody Thu Mar 27 17:53:32 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7464C1A0771; Thu, 27 Mar 2014 17:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25GmKiCwQRef; Thu, 27 Mar 2014 17:53:30 -0700 (PDT) Received: from shell-too.nominum.com (shell-too.nominum.com [64.89.228.229]) by ietfa.amsl.com (Postfix) with ESMTP id 9946F1A076C; Thu, 27 Mar 2014 17:53:30 -0700 (PDT) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C92DA1B8079; Thu, 27 Mar 2014 17:53:28 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 8331D190043; Thu, 27 Mar 2014 17:53:28 -0700 (PDT) Received: from [192.168.146.119] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 17:53:28 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ted Lemon In-Reply-To: <20140327234136.GC51988@mx1.yitter.info> Date: Thu, 27 Mar 2014 19:53:26 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <01AC90A3-77E3-4802-82EA-AC6EEC5C11D1@nominum.com> References: <53349FFB.7050108@qti.qualcomm.com> <20140327233422.GD87785@verdi> <20140327234136.GC51988@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1874) X-Originating-IP: [192.168.1.10] Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/WoaMS7WxlrVimQGSC0D0fza0vmM Cc: IETF Disgust , Pete Resnick , Randy Bush , opsec wg mailing list , The IESG Subject: Re: [OPSEC] Saying no (was: Re: Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 00:53:31 -0000 On Mar 27, 2014, at 6:41 PM, Andrew Sullivan = wrote: > If there's weak IETF consensus (with some strong objections) > to a document that comes from a WG and has strong consensus inside the > WG, the _only_ people who can say no are the IESG; and they must. Not to put words in the responsible AD's mouth, but we do have a process = for dealing with this situation. What it looks like to me is that = there is IETF consensus to publish the document, as long as it comes = with appropriate caveats about applicability. Normally in a situation = like this, there would be text added to the document as a result of IETF = last call comments before the document ever made it to IESG review. From nobody Thu Mar 27 23:43:15 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA321A07F0; Thu, 27 Mar 2014 23:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpOYgjBJPZxD; Thu, 27 Mar 2014 23:43:08 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id BD16F1A0468; Thu, 27 Mar 2014 23:43:07 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id v1so4695623yhn.0 for ; Thu, 27 Mar 2014 23:43:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kZCYJCjtK+lVbbrfzCDk4HGVbwM4toQFJ/RqVSVWku8=; b=NGul5sgBt1lZqiJBP9FuDrYgl6g+Ykbl6asaq5P4j4VSmiQCTL+tZXmJQayJfVNx7q tXu+F+hxRuKry6JMvHEVBPlGuon2WBsoKdr1+SFHUlFrahQRcsza6zCrNF4yKuBE+373 45RMufpuPdMl3ycoXBgdum2njQ9nUEGMkX4pZvqmCt5ZDqAhLupzWOJsaa0auk+G96ZP hJyGeeEFu7X/m4hIbdUIvcUpEOPnBM1Z4ueKeRH6GzI+DvLDp4fg958tw36u7hr364ht L0i/6NzJfw/K6uOfWapiCHsTcmbHYowomSKYztlKBqmdJ+luLbkklHog1j/oaJ7YF3A0 nA2g== MIME-Version: 1.0 X-Received: by 10.236.16.161 with SMTP id h21mr8750500yhh.77.1395988985745; Thu, 27 Mar 2014 23:43:05 -0700 (PDT) Received: by 10.170.87.135 with HTTP; Thu, 27 Mar 2014 23:43:05 -0700 (PDT) In-Reply-To: <20140327234136.GC51988@mx1.yitter.info> References: <53349FFB.7050108@qti.qualcomm.com> <20140327233422.GD87785@verdi> <20140327234136.GC51988@mx1.yitter.info> Date: Fri, 28 Mar 2014 07:43:05 +0100 Message-ID: From: Abdussalam Baryun To: Andrew Sullivan Content-Type: multipart/alternative; boundary=001a11c2aeda9b170604f5a503cd Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/wa3b0oCbcnIKFSfUZFdM5Mn5_c8 Cc: Pete Resnick , opsec wg mailing list , IETF Disgust , The IESG Subject: Re: [OPSEC] Saying no (was: Re: Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 06:43:09 -0000 --001a11c2aeda9b170604f5a503cd Content-Type: text/plain; charset=ISO-8859-1 Hi Andrew I think if the IETF has strong objections with engineering reasons, then it is already a NO. That document should not even get to IESG. We only need IESG decision (saying yes or no) when we all in IETF agree with consensus. All IETF WGs should adapt/amend their document to total IETF consensus (that is WGs interaction). AB On Thursday, March 27, 2014, Andrew Sullivan wrote: > On Thu, Mar 27, 2014 at 07:34:22PM -0400, John Leslie wrote: > > > > The sad truth is, the IESG no longer has the spare cycles to "Just > > say No." > > I was on the receiving end of an IESG that simply stalled a document > until the WG changed its approach, because of IETF concerns, so I > disagree with that claim. But if it is true, then we might as well > give up. If there's weak IETF consensus (with some strong objections) > to a document that comes from a WG and has strong consensus inside the > WG, the _only_ people who can say no are the IESG; and they must. > > Best regards, > > A > > -- > Andrew Sullivan > ajs@anvilwalrusden.com > > --001a11c2aeda9b170604f5a503cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Andrew

I think if the IETF has strong=A0objection= s with engineering=A0reasons, then it is already a NO. That document should= not even get to IESG. We only need IESG decision (saying yes or no)=A0when= we all=A0in=A0IETF agree with consensus. All IETF=A0WGs should adapt/amend= =A0their document to total=A0IETF consensus (that is WGs interaction).=A0

AB

On Thursday, March 27, 2014, Andrew Su= llivan wrote:
On Thu, Mar 27, 2014 at 07= :34:22PM -0400, John Leslie wrote:
>
> =A0 =A0The sad truth is, the IESG no longer has the spare cycles to &q= uot;Just
> say No."

I was on the receiving end of an IESG that simply stalled a document
until the WG changed its approach, because of IETF concerns, so I
disagree with that claim. =A0But if it is true, then we might as well
give up. =A0If there's weak IETF consensus (with some strong objections= )
to a document that comes from a WG and has strong consensus inside the
WG, the _only_ people who can say no are the IESG; and they must.

Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

--001a11c2aeda9b170604f5a503cd-- From nobody Fri Mar 28 04:07:57 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2AC1A03F4; Thu, 27 Mar 2014 16:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQlBjPTXtJJI; Thu, 27 Mar 2014 16:41:44 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id C1AD61A06A8; Thu, 27 Mar 2014 16:41:44 -0700 (PDT) Received: from mx1.yitter.info (69-165-131-253.dsl.teksavvy.com [69.165.131.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 181888A031; Thu, 27 Mar 2014 23:41:42 +0000 (UTC) Date: Thu, 27 Mar 2014 19:41:37 -0400 From: Andrew Sullivan To: John Leslie Message-ID: <20140327234136.GC51988@mx1.yitter.info> References: <53349FFB.7050108@qti.qualcomm.com> <20140327233422.GD87785@verdi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140327233422.GD87785@verdi> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/VC2vAoAFFdrprZeJ_W24KNcj1-Y X-Mailman-Approved-At: Fri, 28 Mar 2014 04:07:54 -0700 Cc: Randy Bush , Pete Resnick , opsec wg mailing list , The IESG , IETF Disgust Subject: [OPSEC] Saying no (was: Re: Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 23:41:46 -0000 On Thu, Mar 27, 2014 at 07:34:22PM -0400, John Leslie wrote: > > The sad truth is, the IESG no longer has the spare cycles to "Just > say No." I was on the receiving end of an IESG that simply stalled a document until the WG changed its approach, because of IETF concerns, so I disagree with that claim. But if it is true, then we might as well give up. If there's weak IETF consensus (with some strong objections) to a document that comes from a WG and has strong consensus inside the WG, the _only_ people who can say no are the IESG; and they must. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Mar 28 05:33:54 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037831A063C; Fri, 28 Mar 2014 05:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mx8u2wXnqqvU; Fri, 28 Mar 2014 05:33:48 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1A91A05D1; Fri, 28 Mar 2014 05:33:47 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,751,1389762000"; d="scan'208";a="245382333" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 28 Mar 2014 08:32:37 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Fri, 28 Mar 2014 08:33:45 -0400 From: "George, Wes" To: Andrew Sullivan , John Leslie Date: Fri, 28 Mar 2014 08:33:44 -0400 Thread-Topic: Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC Thread-Index: Ac9KgfWCSGClf001SNW9FNSLRSJTsw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/oXhKywHpnZRoB1SLTImt1QSf6TE Cc: Pete Resnick , IETF Disgust , opsec wg mailing list , The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 12:33:50 -0000 T24gMy8yNy8xNCwgNzo0MSBQTSwgIkFuZHJldyBTdWxsaXZhbiIgPGFqc0BhbnZpbHdhbHJ1c2Rl bi5jb20+IHdyb3RlOg0KDQoNCj5JZiB0aGVyZSdzIHdlYWsgSUVURiBjb25zZW5zdXMgKHdpdGgg c29tZSBzdHJvbmcgb2JqZWN0aW9ucykNCj50byBhIGRvY3VtZW50IHRoYXQgY29tZXMgZnJvbSBh IFdHIGFuZCBoYXMgc3Ryb25nIGNvbnNlbnN1cyBpbnNpZGUgdGhlDQo+V0csDQoNClJlc3Rvcmlu ZyBzdWJqZWN0IGxpbmUsIGFzIG15IGNvbW1lbnQgaXMgbW9yZSBzcGVjaWZpYyB0byB0aGUgZHJh ZnQsIG5vdA0KZ2VuZXJhbGx5IGFib3V0IOKAnHNheWluZyBub+KAnSwgYnV0IHRoZSBjb21tZW50 IG1hZGUgbWUgd29uZGVyIGFib3V0IHRoZQ0KbGV2ZWwgb2YgY29uc2Vuc3VzLg0KSeKAmWxsIGxl dCB0aGUgY2hhaXJzIHNwZWFrIGZvciB0aGVtc2VsdmVzIGFzIHRvIGhvdyB0aGV5IG1hZGUgdGhl DQpkZXRlcm1pbmF0aW9uIHRoYXQgaXQgd2FzIGFjY2VwdGFibGUgdG8gcHJvY2VlZCwgYW5kIHNp bWlsYXJseSBhdCBXRw0KYWRvcHRpb24gY2FsbCwgYnV0IGluIGxvb2tpbmcgYmFjayBhdCB0aGUg T3BTZWMgbGlzdCBhcmNoaXZlcyB0byB3cml0ZQ0KdGhpcyBtZXNzYWdlLCBJIGRvbuKAmXQgdmll dyB0aGlzIGFzIGhhdmluZyBwYXJ0aWN1bGFybHkgc3Ryb25nIGNvbnNlbnN1cw0Kd2l0aGluIHRo ZSBXRyB0byBwdWJsaXNoLiBUaGUgYWRvcHRpb24gY2FsbCBbMV0gd2FzIOKAnG5vIG9iamVjdGlv buKAnSBhbmQNCndoaWxlIEkgc2VlIHJldmlld3MgYXQgYWRvcHRpb24gY2FsbCwgSSBzZWUgbm8g c3Ryb25nIG1lc3NhZ2VzIG9mIHN1cHBvcnQNCipvciogb3Bwb3NpdGlvbi4gVGhlIFdHTEMgd2Fz IGFjdHVhbGx5IGNvbXBsZXRlZCBvbiB2ZXJzaW9uIC0wMywgaW4gTWFyY2gNCm9mICoyMDEzKiBb Ml0uIFRoZSBkcmFmdCBpcyBub3cgdmVyc2lvbiAtMDcsIGFuZCBubyBuZXcgV0dMQyB3YXMgZG9u ZS4gVGhlDQpyZXZpZXdzIGRvbmUgYXQgV0dMQyBsb29rIHRvIG1lIGxpa2UgdGhlcmUgd2VyZSAz IG9yIDQgaW4gdG90YWwsIG9uZSBvZg0Kd2hpY2ggKG1pbmUpIGV4cHJlc3NlZCBjb25jZXJucyBh Ym91dCB0aGUgZG9jdW1lbnQgcHJvY2VlZGluZyAodGhlIG1lc3NhZ2UNCmlzIHJlZmVyZW5jZWQg aW4gbXkgcHJldmlvdXMgbWVzc2FnZSksIHRoZSBvdGhlcnMgbWFpbmx5IGZvY3VzZWQgb24gdGhl DQpkb2N1bWVudOKAmXMgY29tcGxldGVuZXNzIGFuZCBhY2N1cmFjeSwgbm90IHdoZXRoZXIgaXQg d2FzIGEgZ29vZCBvciBiYWQNCmlkZWEuDQoNCkxpa2UgSm9lbCwgSeKAmW0gbm90IHdpbGxpbmcg dG8gZ28gdG8gdGhlIHdhbGwgKEkuZS4gQXBwZWFsIG9uIHByb2Nlc3MNCmdyb3VuZHMpIHRvIHBy ZXZlbnQgdGhpcyBkcmFmdCBmcm9tIGJlaW5nIHB1Ymxpc2hlZCwgYnV0IEkgdGhvdWdodCB0aGF0 DQp0aGlzIGluZm9ybWF0aW9uIG1pZ2h0IGJlIGhlbHBmdWwgaW4gZGV0ZXJtaW5pbmcgaG93IHRv IHByb2NlZWQuDQoNCldlcyBHZW9yZ2UNCg0KWzFdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvb3BzZWMvc0hubjUybFk4dGlrOVFqVkpjeVV2R01vRTU4DQpbMl0gaHR0cHM6 Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9vcHNlYy9NVTVFLWpnelN1Z043ZzJrU1g3 NDB0aW5FVmsNCg0KQW55dGhpbmcgYmVsb3cgdGhpcyBsaW5lIGhhcyBiZWVuIGFkZGVkIGJ5IG15 IGNvbXBhbnnigJlzIG1haWwgc2VydmVyLCBJDQpoYXZlIG5vIGNvbnRyb2wgb3ZlciBpdC4NCi0t LS0tLS0tLS0tDQoNCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBt YXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hp Y2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBi ZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNv bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQg aXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRo aXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9u LCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0 aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBF LW1haWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Fri Mar 28 07:22:57 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE581A06D1; Fri, 28 Mar 2014 07:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPdrRTLuvEtf; Fri, 28 Mar 2014 07:22:48 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE901A0696; Fri, 28 Mar 2014 07:22:48 -0700 (PDT) Received: by mail-ig0-f179.google.com with SMTP id t19so881311igi.12 for ; Fri, 28 Mar 2014 07:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5BDs48JkmF8dELMwy2pPr5muHo6VWc8bgxvwiEuT+SE=; b=TQiX4UQqTR2vIwGRI/N1/TFI+a7N0s5LKWYCGCsuHV68dJqMVqQkUYigOfFZRrRqQw G5Fx0XIK3AjKxMfJHdlYUJyUjPAAW+HDwMokZpNIyUrnVIz6kU30F2zfJvfZyffUaVUZ ZlXTRMa+mfgQpBsGQfWnCbUYIiirPXC0I+7speo2puBk0kYz/cvwx6Mruv3dGKDk8ydj l2BKyPD/Fz8UUDEcbj2rG7q1CYGvoxPIzMeQFvuHBerpKCuUWnOcslkrV6RIgM8pC50N P3KkdQDhk261fLefwQlx1FyvCCG41zmf8BcYmOwaSzPv8vU7j2bYZznly7lflZzMuEHa BY4Q== MIME-Version: 1.0 X-Received: by 10.43.74.198 with SMTP id yx6mr7786467icb.40.1396016566177; Fri, 28 Mar 2014 07:22:46 -0700 (PDT) Received: by 10.64.11.233 with HTTP; Fri, 28 Mar 2014 07:22:45 -0700 (PDT) In-Reply-To: <20140327210124.GE43641@Space.Net> References: <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> <20140327210124.GE43641@Space.Net> Date: Fri, 28 Mar 2014 10:22:45 -0400 Message-ID: From: Lee To: Gert Doering Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/bHPHb8nm1LrpHYrwUNcWSXdBRPI Cc: The IESG , opsec@ietf.org, Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 14:22:49 -0000 Hi Gert, On 3/27/14, Gert Doering wrote: > Hi, > > On Thu, Mar 27, 2014 at 10:42:23AM -0400, Lee wrote: >> And to ratchet the level of hyperbole down a notch, enabling uRPF can lead >> to >> - not being able to specifically ping one particular interface from >> the management system >> - not having traceroute tell me on which exact path my packets are >> flowing >> - NMS/discovery limitations >> and yet enabling uRPF is generally considered A Good Idea. > > Actually, enabling uRPF on core-to-core interfaces is considered a > significantly stupid idea. You enable uRPF towards your customers, > and loose(!) uRPF towards peers/upstreams for BGP-RTBH. Is there an RFC that spells it out that clearly? I couldn't find anything about 3 years ago when an auditor from our security office, using the CIS Secure IOS benchmark, decided that every router interface needed uRPF enabled. You want fun, try explaining asymmetrical routing to an auditor. > None of these will impair traceroute or NMS/discovery. If you only do uRPF at the edge - right, it doesn't impair traceroute but it did give us grief with NMS/discovery: NMS 10.10.10.10 | core / \ / \ distA distB |10.1.1.3 | 10.1.1.4 | | --- access --- When the access layer switch says it's neighbors are 10.1.1.3 and 10.1.1.4 we had problems. Maybe it was just the discovery software being stupid, but we ended up putting every device into the discovery seed file. Lee From nobody Fri Mar 28 08:44:56 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9881A0705 for ; Fri, 28 Mar 2014 08:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMYKI_dezsdO for ; Fri, 28 Mar 2014 08:44:50 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id DDE461A06E3 for ; Fri, 28 Mar 2014 08:44:49 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h18so989700igc.2 for ; Fri, 28 Mar 2014 08:44:47 -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; bh=qN8FMxvYDpwfSW9r7nd5wGoUJtmACf2rJNK6KkyH6pA=; b=d0QjfoXCrt/SvrDIPE6nC03IV5a49Zkn7fy3/SU7k6AE7OjqN9KiDGNIyUYkxjvlwe DB3Be7PDRS6P5mEexRrVoQgAuSrXoR4I+ECHKF6UrdDzCBFhA4Dg+77U26EDpe/KkQdD mmvY+9MO8x5jjLtNaELyzejpeeE+/QHCche48x8MUynUscC3rkUjyHqpBwKCWsRDy232 UzuEtku7vmHHGnelVbmc5RQ+GHDiVN/URie1oOigQlj/Wh4M6OC6o7AEl+xqdmwGJOut u63wCW+tPtA32sYP1myybYNZDoHRtSpzAqF1cpw04gQFsG033ZWQax3gY9m7YsvC5iix KBug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=qN8FMxvYDpwfSW9r7nd5wGoUJtmACf2rJNK6KkyH6pA=; b=XrYDWG/6Ujh+H0yWnH6TjUuU4jTSomDCha92LK5jT7yX5MymSiURZ/bMj4ZK+qCJVv AW8QAC79MKhODu2uwbAvTTNRq+Y9YP2rHsTpOeHT5gAWzxCvecjxzJRkiAJPdkpTaa6C oAPXsBd2jW4oUNtC8zX0vGGvqgmNeiUgeiQmKQTQlQc80w/Gir/Wn5bHS935+skZ2q/m lmfnlFlgBj/G8wk6fryFHbStVEOl1TrRinLIi92N3LbymKrj4HHt5oprpNOrjcWwu/TF Au0AB+i2caHC8XxaLAomOaOsyneBC5kEuKH4ZgKCaD9ZKipPNcT/rqkcnjkIYShhU8IH HYWA== X-Gm-Message-State: ALoCoQnNTclVO+oee2QkRhrZ19b63ANG6XCNr5Zsw/b2otc81h+fyKrJj0SuQBFQoS1VQ6cwXuUf0/V3kSieGbHfZ0NZJpy+sz5P47Wa0CFICbTvd+2gRQQkRlPQAbn8luWgDYw2MiHmLxKFIAMqQqa8A6vRoyQH8KbP7wSZkyu87g/A+j+Wz5RBIqr7ua4ZIpBEtQmduRsd X-Received: by 10.43.50.65 with SMTP id vd1mr1324573icb.79.1396021487611; Fri, 28 Mar 2014 08:44:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.201.162 with HTTP; Fri, 28 Mar 2014 08:44:27 -0700 (PDT) From: KK Date: Fri, 28 Mar 2014 08:44:27 -0700 Message-ID: To: "opsec@ietf.org" Content-Type: multipart/alternative; boundary=bcaec529a01fde524d04f5ac944b Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/OB03VuRGxtqX2KxzfJ3NsY65E7I Subject: [OPSEC] Start of WGLC for draft-ietf-opsec-dhcpv6-shield X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 15:44:52 -0000 --bcaec529a01fde524d04f5ac944b Content-Type: text/plain; charset=UTF-8 Dear OpSec WG, This starts a Working Group Last Call for draft-ietf-opsec-dhcpv6-shield The draft is available here: https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/ Please review this draft to see if you think it is ready for publication. Send comments to the list, clearly stating your view. This WGLC ends Friday 11-Apr-2014. Thanks, KK (as OpSec WG co-chair) --bcaec529a01fde524d04f5ac944b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Dear OpSec WG,


This starts a Working Group Last Call for draft-ietf-opsec-dhcpv6-sh= ield


The draft is available here:=C2=A0https://datatracker.ietf.org/doc= /draft-ietf-opsec-dhcpv6-shield/


=

Pl= ease review this draft to see if you think it is ready for publication.


Se= nd comments to the list, clearly stating your view.


Th= is WGLC ends Friday 11-Apr-2014.


Th= anks,

KK

(a= s OpSec WG co-chair)
--bcaec529a01fde524d04f5ac944b-- From nobody Fri Mar 28 10:18:17 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 162EA1A0939 for ; Fri, 28 Mar 2014 10:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZZt_EozXpjr for ; Fri, 28 Mar 2014 10:17:58 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 43E761A0934 for ; Fri, 28 Mar 2014 10:17:57 -0700 (PDT) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 8937760B1F for ; Fri, 28 Mar 2014 18:17:54 +0100 (CET) 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 4B0546042C for ; Fri, 28 Mar 2014 18:17:54 +0100 (CET) Received: (qmail 72926 invoked by uid 1007); 28 Mar 2014 18:17:54 +0100 Date: Fri, 28 Mar 2014 18:17:54 +0100 From: Gert Doering To: Lee Message-ID: <20140328171754.GB43641@Space.Net> References: <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> <20140327210124.GE43641@Space.Net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2qkyu1R6kqeK19z+" Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/Hz0_HMPdLGg4ya15RIJxv7aJxWY Cc: The IESG , opsec@ietf.org, Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 17:18:02 -0000 --2qkyu1R6kqeK19z+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri, Mar 28, 2014 at 10:22:45AM -0400, Lee wrote: > > Actually, enabling uRPF on core-to-core interfaces is considered a > > significantly stupid idea. You enable uRPF towards your customers, > > and loose(!) uRPF towards peers/upstreams for BGP-RTBH. >=20 > Is there an RFC that spells it out that clearly? =20 Well, I never searched. I find that so blindingly obvious that I never assumed someone would want to do that, and not understand why it hurts. > I couldn't find > anything about 3 years ago when an auditor from our security office, > using the CIS Secure IOS benchmark, decided that every router > interface needed uRPF enabled. You want fun, try explaining > asymmetrical routing to an auditor. Yeah, I can feel your pain. OTOH in certain situations there's not much you can do except "call his supervisor, declare the auditor to be defective, RMA". > > None of these will impair traceroute or NMS/discovery. >=20 > If you only do uRPF at the edge - right, it doesn't impair traceroute > but it did give us grief with NMS/discovery: >=20 > NMS 10.10.10.10 > | > core > / \ > / \ > distA distB > |10.1.1.3 | 10.1.1.4 > | | > --- access --- >=20 > When the access layer switch says it's neighbors are 10.1.1.3 and > 10.1.1.4 we had problems. Maybe it was just the discovery software > being stupid, but we ended up putting every device into the discovery > seed file. Mmmh. Unless something weird comes into play here, I can't see how uRPF could interfere if none of the links you have shown (core<->dist<-> access) has uRPF enabled... 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 (0)89/32356-444 USt-IdNr.: DE813185279 --2qkyu1R6kqeK19z+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBUzWuwt9WwGXkzn/FAQLH/w/+J+EuxCvCjN4ixC9SplDeACB95KlJlQ0v 8/i80LnmLSc2NO4R0E/lKRPtw0dliPXM/BJEcVYm+8yXLimHKEsOOsgH4c0bZoUh 2vC1lRRyg7FRNFeDWW0EbEkCNwoAoKVhfvHI/qw8lyggfz39rrH7U6wLNazjS7AL gjRBcQjc748LvAtgB2IjsRqk8e1SoDSLSpxe3grtKEIb1afj6mg8Lrn4ww1QoX3L UIkOJgrzaEtQOuPv6Wl0XSElqNVZx4Vv/dwxw7e4okOxy7zmnzpZEW3MQzwvBtlR NDjSnmqoaOreGw4906gIIlG+t6YagcLux3XUUe4ouQ+1jnp8s52sS/j3RDaXM9Mh Uwfzr2wJylzt/LCYZTH/VargTOrhR54OKKLK5yn2al/RTOfmhzatf/A2ExB5Rb08 RGfUq2ZyphTIFzPn33zPwlUIOOe2fh3mZhFKsVlTxOLv5/4yYQipKBSwJlLVmjL2 01jaKy2Z76m3RGXx90DK9K+zAI63sAChf7A5XlCziqjjGPjhwwwxFoQi6/cVcrBn EOyTRxaCVJMWuWRUzuHZM1bpcs1wzRvyLU//ZxzrQI2Dr1A7EGLQ2NF0kVLnNTCm nIoOEsKuXkg+/mUl5jVeJ0gW6J1Jgp1ovceNkSmZkaq/RCzUkBI/Rhx2gKYdlnPJ o45s5OAniOI= =WWRU -----END PGP SIGNATURE----- --2qkyu1R6kqeK19z+-- From nobody Fri Mar 28 10:35:26 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02A91A0700; Fri, 28 Mar 2014 10:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrZB7tRrUv4g; Fri, 28 Mar 2014 10:35:19 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 40D701A00DD; Fri, 28 Mar 2014 10:35:19 -0700 (PDT) Received: from [IPv6:2601:4:2180:300:a938:8be6:86a0:59a2] ([IPv6:2601:4:2180:300:a938:8be6:86a0:59a2]) (authenticated bits=0) by puck.nether.net (8.14.8/8.14.5) with ESMTP id s2SHZCce023779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 28 Mar 2014 13:35:13 -0400 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Fri, 28 Mar 2014 13:35:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <41AB09A4-44F7-40C7-9730-B847DA851641@puck.nether.net> References: <20140324155135.3745.38775.idtracker@ietfa.amsl.com> <84B06092-8262-4256-B0C6-DF22FE75BA02@nominum.com> <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> <53344243.1060101@bogus.com> To: Christopher Morrow X-Mailer: Apple Mail (2.1874) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.7 (puck.nether.net [IPv6:2001:418:3f4::5]); Fri, 28 Mar 2014 13:35:14 -0400 (EDT) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/2iA2CLFRwGTCfXTSeIGghScn690 Cc: Randy Bush , opsec wg mailing list , The IESG , Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 17:35:21 -0000 On Mar 27, 2014, at 2:24 PM, Christopher Morrow = wrote: > On Thu, Mar 27, 2014 at 11:22 AM, joel jaeggli = wrote: >> I think when were were discussing this in the w.g. that it has the >> potential to make things such as recursive next-hop calculation much >=20 > yup, certainly... you probably have to think long and hard about any > standard advice from vendors/third-parties about configuration > optimizations ;( >=20 >> harder since using link-local-scope addresses that aren't on-link for >> you would seem problematic. maybe using the loopback is an acceptable >> alterntive for some applications but you loose access to some tools = this way >=20 > see my comment about complexity... oh, included below, how nice of you = :) >=20 >>> complexity is going to cause you pain, it is going to cause you >>> problems and it is going to lengthen outages :( avoid complexity. I think this is the critical element, many things here will cause pain. Using link-local for these purposes has so many unintended side-effects it's not something anyone rational will deploy. Just because I can = stick a pencil in my eye doesn't mean it's a good idea nor something I should write a how-to document for. I have a redundant eye, but at some point the consequences are likely to be quite catastrophic. - Jared= From nobody Fri Mar 28 12:49:28 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6103F1A01D8; Fri, 28 Mar 2014 12:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ONIYg0YF35B; Fri, 28 Mar 2014 12:49:26 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E8DD01A01CC; Fri, 28 Mar 2014 12:49:25 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id to1so5221283ieb.6 for ; Fri, 28 Mar 2014 12:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zX0pYeP52skWO4p3b7yjBr0BSIxpKJHyjd7fjY79qEM=; b=gnA+PfbN0RIA27G1XJ/xzCaRfsbxPsuWQKsLQkJPWGVpfeaNPBTahYVknaArSUUJGh FMQwDTCUYshsFzrJTcg9d9CyEL4HgLAUt+8BXF1S08oog4ZDr7VXWmzFtx4dpispNrku 0F9jZGh8Hu+nTlKK+dBYA0qSLiwaAMbf94r/ilTXXYjL32VN9L2wGGWqYAos5lhlVBo+ eYhiSQ1ohamhUb8lP7UQf8V3TUB/vhsPu9UKQqpsAxw4UODKHylocaBiouqTauC81RCw PwKAqcgkKNM1jy8tCxNLrOSw3hYFnMASx+N3NagpsqfRChjVVQI9ajNMv9fxpPBtgunZ GEfg== MIME-Version: 1.0 X-Received: by 10.43.74.198 with SMTP id yx6mr9394210icb.40.1396036163616; Fri, 28 Mar 2014 12:49:23 -0700 (PDT) Received: by 10.64.11.233 with HTTP; Fri, 28 Mar 2014 12:49:23 -0700 (PDT) In-Reply-To: <20140328171754.GB43641@Space.Net> References: <9C78F8C0-AA07-4F11-8D74-9995366020E2@nominum.com> <20140326102130.GR43641@Space.Net> <20140327210124.GE43641@Space.Net> <20140328171754.GB43641@Space.Net> Date: Fri, 28 Mar 2014 15:49:23 -0400 Message-ID: From: Lee To: Gert Doering Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/BT2hfxR4DvaLjclDLyi-WbtuLHk Cc: The IESG , opsec@ietf.org, Ted Lemon Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 19:49:27 -0000 On 3/28/14, Gert Doering wrote: > Hi, > > On Fri, Mar 28, 2014 at 10:22:45AM -0400, Lee wrote: >> > Actually, enabling uRPF on core-to-core interfaces is considered a >> > significantly stupid idea. You enable uRPF towards your customers, >> > and loose(!) uRPF towards peers/upstreams for BGP-RTBH. >> >> Is there an RFC that spells it out that clearly? > > Well, I never searched. I find that so blindingly obvious that I never > assumed someone would want to do that, and not understand why it hurts. Which is why I tried to summarize the caveats for this draft earlier. Sometimes it seems like the experts think something is so blindingly obvious they don't need to document it -- which leaves the non-experts to blindly follow "best practices" or learn the hard way. >> I couldn't find >> anything about 3 years ago when an auditor from our security office, >> using the CIS Secure IOS benchmark, decided that every router >> interface needed uRPF enabled. You want fun, try explaining >> asymmetrical routing to an auditor. > > Yeah, I can feel your pain. OTOH in certain situations there's not > much you can do except "call his supervisor, declare the auditor to > be defective, RMA". I tried that :) >> > None of these will impair traceroute or NMS/discovery. >> >> If you only do uRPF at the edge - right, it doesn't impair traceroute >> but it did give us grief with NMS/discovery: >> >> NMS 10.10.10.10 >> | >> core >> / \ >> / \ >> distA distB >> |10.1.1.3 | 10.1.1.4 >> | | >> --- access --- >> >> When the access layer switch says it's neighbors are 10.1.1.3 and >> 10.1.1.4 we had problems. Maybe it was just the discovery software >> being stupid, but we ended up putting every device into the discovery >> seed file. > > Mmmh. Unless something weird comes into play here, I can't see how > uRPF could interfere if none of the links you have shown (core<->dist<-> > access) has uRPF enabled... Sorry - I grabbed an old msg describing the problem and cut a bit too much. The access layer is an L2 switch so uRPF is enabled on the 10.1.1.3 and 10.1.1.4 interfaces at the distribution layer. The nms machine tries to ping 10.1.1.3 (or tries to discover 10.1.1.3 - same problem) The core router sees two equal cost paths to the 10.1.1 network. If core routes the packet to distB the unicast RPF check passes on distB (source addr 10.10.10.10 is routed via distB-core link) and distB forwards the packet over the 10.1.1 access network to distA. The RPF check fails on distA because the route to 10.10.10.10 is via the distA-core link, not via the 10.1.1 access network interface that the packet came in on. Lee From nobody Sat Mar 29 00:19:23 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62161A0132 for ; Sat, 29 Mar 2014 00:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFEI-FD3XByC for ; Sat, 29 Mar 2014 00:19:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 09AEA1A0087 for ; Sat, 29 Mar 2014 00:19:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFA98869; Sat, 29 Mar 2014 07:19:11 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 29 Mar 2014 07:18:36 +0000 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 29 Mar 2014 07:19:09 +0000 Received: from szxeml557-mbs.china.huawei.com ([169.254.6.77]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Sat, 29 Mar 2014 15:19:03 +0800 From: Tina TSOU To: joel jaeggli , "opsec@ietf.org" , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , opsec chairs Thread-Topic: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. Thread-Index: AQHPSx8o4Z0/FITL0UOl+kvOkhKTIw== Date: Sat, 29 Mar 2014 07:19:02 +0000 Message-ID: References: <532EF647.1030201@bogus.com> In-Reply-To: <532EF647.1030201@bogus.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.87.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/EGbIAt6Pi9Nyiz_DN1lvGYjPNEI Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 07:19:19 -0000 Dear Joel et al, For question 1, This document does not describe disabling IPv6 as a desired outcome, but ra= ther notes that in some scenarios, it might be the only option left to miti= gate VPN leakages. Thank you, Tina -----Original Message----- From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of joel jaeggli Sent: Sunday, March 23, 2014 10:57 PM To: opsec@ietf.org; draft-ietf-opsec-vpn-leakages.all@tools.ietf.org; opsec= chairs Subject: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from = the IESG. Hi, I hope that you folks are recovering well from IETF meeting related excesse= s and accompanying travel. Some questions came up in the IESG review of the document that are more app= ropriately answered by the working group rather than by me attempting to ch= annel you folks. https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ 1. Does the working-group view view disabling IPV6 in deployed equipment du= e to operational necessity as a desirable outcome. 2. Does the working-group characterize the problem of vpn leakages captured= in this document as being distinct from the problems posed by split-tunnel= s in general. Your thoughts would be appreciated. joel From nobody Sat Mar 29 07:27:07 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA2F1A0535 for ; Sat, 29 Mar 2014 07:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWv0-PqcVD2r for ; Sat, 29 Mar 2014 07:27:01 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id AD0C51A0503 for ; Sat, 29 Mar 2014 07:27:01 -0700 (PDT) Received: from mb-aye.lan (50-0-150-57.dsl.static.sonic.net [50.0.150.57]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s2TEQoUj026526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 29 Mar 2014 14:26:50 GMT (envelope-from joelja@bogus.com) Message-ID: <5336D829.8040004@bogus.com> Date: Sat, 29 Mar 2014 07:26:49 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <532EF647.1030201@bogus.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HFca7t1LjPTdXkmlxhAcLKnK0eJEd80MA" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sat, 29 Mar 2014 14:26:52 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ODjRRUfviByv1FPrKxOzNNiZHQo Cc: "opsec@ietf.org" , opsec chairs , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 14:27:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HFca7t1LjPTdXkmlxhAcLKnK0eJEd80MA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 3/23/14, 10:39 AM, Carlos Pignataro (cpignata) wrote: > Joel, Warren (as shepherd), >=20 > In addition to some responses below, it appears that my review > comments sent to opsec are yet to be addressed:=20 > http://www.ietf.org/mail-archive/web/opsec/current/msg01477.html "The > only remaining bit is the issue raised by Carlos which we'll=20 > hopefully address in the next rev."=20 > http://www.ietf.org/mail-archive/web/opsec/current/msg01447.html >=20 > It seems the remaining bit is still remaining. Frankly, I am still > concerned that this doc still refers to "VPN Leakages" while its > applicability and scope is a small subset of "VPNs". the problem I take it with respect to aplicability is that the draft targets a narrow subset of vpns. The problem of exposure via split tunnels or in fact multi-interface issues is covers a whole range of issues, some of which are deliberate, some accidental or in this case inadvertent. > More inline. >=20 > On Mar 23, 2014, at 10:57 AM, joel jaeggli wrote: >=20 >> Hi, >>=20 >> I hope that you folks are recovering well from IETF meeting >> related excesses and accompanying travel. >>=20 >> Some questions came up in the IESG review of the document that are >> more appropriately answered by the working group rather than by me >> attempting to channel you folks. >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ >>=20 >> 1. Does the working-group view view disabling IPV6 in deployed >> equipment due to operational necessity as a desirable outcome. >=20 > My personal view is "No". That would be a step backwards in deploying > IPv6. >>=20 >> 2. Does the working-group characterize the problem of vpn leakages=20 >> captured in this document as being distinct from the problems posed >> by split-tunnels in general. >>=20 >=20 > I do not think it is different. Rather, this is one instantiation of > a more general problem. >=20 > Thanks, >=20 > -- Carlos. >=20 >> Your thoughts would be appreciated. joel >>=20 >>=20 >> _______________________________________________ OPSEC mailing list=20 >> OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec >=20 --HFca7t1LjPTdXkmlxhAcLKnK0eJEd80MA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM22CoACgkQ8AA1q7Z/VrKsZACdGELV/QMhL8mD69wsBVZS3/co zmYAn2jrHhAmvTcj9dMa+dPxeTSrG8EY =Jy2z -----END PGP SIGNATURE----- --HFca7t1LjPTdXkmlxhAcLKnK0eJEd80MA-- From nobody Sat Mar 29 09:19:18 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B551A07C3 for ; Sat, 29 Mar 2014 09:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5WGrgd8ARP3 for ; Sat, 29 Mar 2014 09:19:11 -0700 (PDT) Received: from mobil.space.net (mobil.space.net [IPv6:2001:608:2:81::67]) by ietfa.amsl.com (Postfix) with ESMTP id 4793F1A06D9 for ; Sat, 29 Mar 2014 09:19:10 -0700 (PDT) Received: from mobil.space.net (localhost [IPv6:::1]) by mobil.space.net (Postfix) with ESMTP id 605A5604B0 for ; Sat, 29 Mar 2014 17:19:07 +0100 (CET) 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 1FECA602AB for ; Sat, 29 Mar 2014 17:19:07 +0100 (CET) Received: (qmail 26379 invoked by uid 1007); 29 Mar 2014 17:19:07 +0100 Date: Sat, 29 Mar 2014 17:19:07 +0100 From: Gert Doering To: joel jaeggli Message-ID: <20140329161907.GG43641@Space.Net> References: <532EF647.1030201@bogus.com> <5336D829.8040004@bogus.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xUmkiJWWU9u+si2r" Content-Disposition: inline In-Reply-To: <5336D829.8040004@bogus.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/dsD90z9HI0Qgs21apafWX892pjo Cc: "Carlos Pignataro \(cpignata\)" , "opsec@ietf.org" , opsec chairs , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 16:19:14 -0000 --xUmkiJWWU9u+si2r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Mar 29, 2014 at 07:26:49AM -0700, joel jaeggli wrote: > the problem I take it with respect to aplicability is that the draft > targets a narrow subset of vpns. The problem of exposure via split > tunnels or in fact multi-interface issues is covers a whole range of > issues, some of which are deliberate, some accidental or in this case > inadvertent. Well, one could argue that for the case of split tunnels, this is a deliberate decision by the admin setting this up. For v4/v6 "split", it might not be a conscious decision, but a lack of proper software support - and in any case, I find it useful to raise awareness about this problem. Actually, looking at this from a different angle, namely that of a=20 developer of such VPN software, it's surprisingly difficult to make=20 "full tunneling" work with IPv6 in a hostile network - if you do not=20 want to go to "make a kernel module that overrides any routing decision=20 at lowest level", but take the portable approach OpenVPN does ("install=20 routes to a 'tun' interface, which hands the packet to userland for=20 encryption and forwarding"), it is really really hard to ensure that=20 *all* packets go into the tunnel, and nobody installs extra routes=20 via RA+PIO or RIO behind your back, siphoning off traffic to those destinations. In a portable way across 7 unix platforms and 3 windows variants. 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 (0)89/32356-444 USt-IdNr.: DE813185279 --xUmkiJWWU9u+si2r Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUBUzbyet9WwGXkzn/FAQIvPQ/+L8QNnLVwDby6O7SwRj80Qko9dKdlelRu pdpM6zSM3TYA6xyBAgUIB03Pz5Y2OBBNHuYE2xku7rNsJtXtfbHdI1v+PbnJy2f8 c0CjNS6gpx3mBNVyd93OIDZ1Vif6jS6vRzC5iTAuXhFntFWMsWyo7OF72ghlUZ+r sX3GBHN8BloWDCvU26QBlUspRBUJTS0XJiFLoYQB4W4J52cYEAgln2FzLODA5uNy hjFyRrCrj0nb98Cx/X0mgJIl4kV3As+z3HK2RbRIkZWj2m1tzJC0p5wHbqkVYCVL V+zUvmMUAWa/1shwYupr/kOCAmp+WCLr4tMpddsOC6ilhzF66rxKqmTK8XDh4Akx EerTn0av6oIdF93yw9qM/RFosJrfl28PPB1ui1T5snpfwNB8fm5zV+MD9atfSERU 4EZfHsa4Cli32nwiHqK0Xv1YjcO4fxXLQLvlzOVeDU7584dvMjBIjGzOJaaBd9Ra g8LnReTOeV64evsiaS9cMc1PbuaSu9CT+5mv8zes5Try0AmN9HXWj0VzX3bR9UQN 7oyERUsApQNjyl64QwytBCUUBQ4opZkzlasRuJE6avOrRxlMwZFl6zb3bKBSWHfU lgVIzqWc3rfTXrqnBkkj+Hr8ObcNnC4fgGNJpK62i9sfTPRJozTgbKO/RnxPR9Ay KSSKXBBRS30= =FqRV -----END PGP SIGNATURE----- --xUmkiJWWU9u+si2r-- From nobody Sat Mar 29 16:46:38 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B2B1A07F5 for ; Sat, 29 Mar 2014 16:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQv_QU5GsU6g for ; Sat, 29 Mar 2014 16:46:34 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECC91A07EC for ; Sat, 29 Mar 2014 16:46:34 -0700 (PDT) Received: from [186.137.77.143] (helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WU2x4-0006sI-DB; Sun, 30 Mar 2014 00:46:14 +0100 Message-ID: <53375AAD.4060000@si6networks.com> Date: Sat, 29 Mar 2014 20:43:41 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: joel jaeggli , "Carlos Pignataro (cpignata)" References: <532EF647.1030201@bogus.com> <5336D829.8040004@bogus.com> In-Reply-To: <5336D829.8040004@bogus.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ew5j9LEHbbmysWolT5cfZxZrOh4 Cc: "opsec@ietf.org" , opsec chairs , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 23:46:37 -0000 Joel, On 03/29/2014 11:26 AM, joel jaeggli wrote: >> >> In addition to some responses below, it appears that my review >> comments sent to opsec are yet to be addressed: >> http://www.ietf.org/mail-archive/web/opsec/current/msg01477.html >> "The only remaining bit is the issue raised by Carlos which we'll >> hopefully address in the next rev." >> http://www.ietf.org/mail-archive/web/opsec/current/msg01447.html >> >> It seems the remaining bit is still remaining. Frankly, I am >> still concerned that this doc still refers to "VPN Leakages" >> while its applicability and scope is a small subset of "VPNs". > > the problem I take it with respect to aplicability is that the > draft targets a narrow subset of vpns. The problem of exposure via > split tunnels or in fact multi-interface issues is covers a whole > range of issues, some of which are deliberate, some accidental or > in this case inadvertent. As noted by Gert and myself, this document raises awareness about a specific (yet common) problem scenario where, as a result of the interactions between IPv4 and IPv6, your traffic may (either deliberately or inadvertently) leak out of your VPN software. This problem has affected (and in some cases "is still affecting") products from vendors (Cisco, Juniper, OpenVPN, etc.). The solution, as noted by Gert, is non-trivial. Raising awareness of this issue has led a number of folks (including vendors) from at least paying attention and consider doing something about this. And, at the same time, for folks employing the said VPN software to be aware of these issues. This kind of thing should be an indication of why the document is important. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Sun Mar 30 09:37:47 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6171A0896 for ; Sun, 30 Mar 2014 09:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbXWECzu2th8 for ; Sun, 30 Mar 2014 09:37:41 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id B5BFA1A06EA for ; Sun, 30 Mar 2014 09:37:41 -0700 (PDT) Received: from mb-aye.local (c-50-174-19-240.hsd1.ca.comcast.net [50.174.19.240]) (authenticated bits=0) by nagasaki.bogus.com (8.14.7/8.14.7) with ESMTP id s2UGbbKq033902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 30 Mar 2014 16:37:37 GMT (envelope-from joelja@bogus.com) Message-ID: <5338484C.5070900@bogus.com> Date: Sun, 30 Mar 2014 09:37:32 -0700 From: joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Thunderbird/28.0 MIME-Version: 1.0 To: "opsec@ietf.org" , "draft-ietf-opsec-vpn-leakages.all@tools.ietf.org" , opsec chairs References: <532EF647.1030201@bogus.com> In-Reply-To: <532EF647.1030201@bogus.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="heaxTpDmqlfI5n2K8N16vTfu0SiR1S4Cb" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (nagasaki.bogus.com [147.28.0.81]); Sun, 30 Mar 2014 16:37:39 +0000 (UTC) Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/N1qst26rSF7WTjvKtJwGZwNEX2U Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 16:37:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --heaxTpDmqlfI5n2K8N16vTfu0SiR1S4Cb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable wrapping up. On 3/23/14, 7:57 AM, joel jaeggli wrote: > Hi, >=20 > I hope that you folks are recovering well from IETF meeting related > excesses and accompanying travel. >=20 > Some questions came up in the IESG review of the document that are more= > appropriately answered by the working group rather than by me attemptin= g > to channel you folks. >=20 > https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ >=20 > 1. Does the working-group view view disabling IPV6 in deployed equipmen= t > due to operational necessity as a desirable outcome. Feedback I heard was. Not desirable, sometimes necessary. Dovetails with 7123 advice. Tweak the applicability/language so it probably represents the subset of vpns to which this applies. As a vpn developer it is in fact hard to prevent route inject even in the v6 supporting case. > 2. Does the working-group characterize the problem of vpn leakages > captured in this document as being distinct from the problems posed by > split-tunnels in general. With respect to the deliberate of the choice yes. as a distinct class of problem no, also applies to v6 supporting vpn applications used deliberately. > Your thoughts would be appreciated. Thanks, this is information that I can use with the IESG. > joel >=20 >=20 >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec >=20 --heaxTpDmqlfI5n2K8N16vTfu0SiR1S4Cb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlM4SEwACgkQ8AA1q7Z/VrLnbgCfUkvpkaQ1n7icWx/upS7uA5Z4 aOwAoIdhimQG5HQ+sgNqxqGsB+zH2NmQ =oGwc -----END PGP SIGNATURE----- --heaxTpDmqlfI5n2K8N16vTfu0SiR1S4Cb-- From nobody Sun Mar 30 18:52:01 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A901A08C7 for ; Sun, 30 Mar 2014 18:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSsu-bEw3RTC for ; Sun, 30 Mar 2014 18:51:58 -0700 (PDT) Received: from mail-vc0-x236.google.com (mail-vc0-x236.google.com [IPv6:2607:f8b0:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0C82A1A03E9 for ; Sun, 30 Mar 2014 18:51:57 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id ks9so7692300vcb.41 for ; Sun, 30 Mar 2014 18:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=NPe0gz7l8V67SxmYynPwxLZrWP8ba0jJ/8CTpAT501U=; b=rqUMTlVTVATLwhWa7xUyyLHzA0TBBjZsCsxBUNzdPeqIW6bF5SgqBn2yh1rO0IDKbZ QMBHiE79jHNRYk8ZiZMA9SxmWrDwdwiT4Ua4xQVSoA52YQ0oCgk4DlJZRieAkxYedFFQ t4iyE4q+6OhcubTYJIM1Ar2i1WVH/b/Cm0d1+s2FfpWgSRS8SjDFY3pYfqWvTlW6jnQ9 KoLxz2s+6U5RpC24pu/IRjwwALn/ZFu9RuyXxkyz3hLkH0Z5Sa3bKch7WZGregGjYZr3 ikE/i0oAeEQ/mIFU6GZzudqOLIjEZXpAuCsl6cgMNrlsHsEMsSZKJtTUG/r9u5LzcpWz 7XUw== X-Received: by 10.58.57.4 with SMTP id e4mr2634073veq.7.1396230714846; Sun, 30 Mar 2014 18:51:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.142.143 with HTTP; Sun, 30 Mar 2014 18:51:14 -0700 (PDT) From: Qiong Date: Mon, 31 Mar 2014 09:51:14 +0800 Message-ID: To: opsec@ietf.org Content-Type: multipart/alternative; boundary=001a1136a364c873f404f5dd4b75 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/onMbrCV58hfeLiaCUdt6AljJurU Subject: Re: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 01:52:00 -0000 --001a1136a364c873f404f5dd4b75 Content-Type: text/plain; charset=UTF-8 Hi all, Here is some of my considerations on the second question. I think the problem described in this document is different from that of split tunneling. Some reasons below: 1) It describes a compromise of a VPN. 2) It results from a particular interaction between both IP protocol families. Hope it clarifies. Thanks. Best wishes -- ============================================== Qiong Sun China Telecom Beijing Research Institute Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/ * PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of joel jaeggli Sent: Sunday, March 23, 2014 10:57 PM To: opsec@ietf.org; draft-ietf-opsec-vpn-leakages.all@tools.ietf.org; opsec chairs Subject: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions from the IESG. Hi, I hope that you folks are recovering well from IETF meeting related excesses and accompanying travel. Some questions came up in the IESG review of the document that are more appropriately answered by the working group rather than by me attempting to channel you folks. https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/ 1. Does the working-group view view disabling IPV6 in deployed equipment due to operational necessity as a desirable outcome. 2. Does the working-group characterize the problem of vpn leakages captured in this document as being distinct from the problems posed by split-tunnels in general. Your thoughts would be appreciated. joel --001a1136a364c873f404f5dd4b75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Here is some of my consideratio= ns on the second question.=C2=A0

I think the = problem described in this document is different from that of split=20 tunneling. Some reasons below:
1) It describes a compromise of a VPN.
2) It results from a particular interaction between both IP protocol= =20 families.

Hope it clarifies. Thanks.
Best wishes

--
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Beiji= ng Research Institute


Open source code:
lightweight 4over6: http://sourceforge.net/projec= ts/laft6/
PCP-natcoord: http://sourceforge.net/projects/pc= pportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From: OPSEC [mailto:ops= ec-bounces@ietf.org] On Behalf Of joel jaeggli
Sent: Sunday, March 23, 2014 10:57 PM
Subject: [OPSEC] draft-ietf-opsec-vpn-leakages - clarifying questions = from=20 the IESG.
=C2=A0
Hi,
=C2=A0
I hope that you folks are recovering well from IETF meeting related=20 excesses and accompanying travel.
=C2=A0
Some questions came up in the IESG review of the document that are mor= e=20 appropriately answered by the working group rather than by me attempting to= =20 channel you folks.
=C2=A0
https://datatracker.ietf.org/doc/draft-ietf-opsec-vpn-leakages/
=C2=A0
1. Does the working-group view view disabling IPV6 in deployed equipme= nt=20 due to operational necessity as a desirable outcome.
=C2=A0
2. Does the working-group characterize the problem of vpn leakages cap= tured=20 in this document as being distinct from the problems posed by split-tunnels= in=20 general.
=C2=A0
Your thoughts would be appreciated.
joel
--001a1136a364c873f404f5dd4b75-- From nobody Sun Mar 30 19:31:25 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BFA1A0927 for ; Sun, 30 Mar 2014 19:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK0h88E5GjUw for ; Sun, 30 Mar 2014 19:31:20 -0700 (PDT) Received: from mail-vc0-x230.google.com (mail-vc0-x230.google.com [IPv6:2607:f8b0:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 969171A090D for ; Sun, 30 Mar 2014 19:31:20 -0700 (PDT) Received: by mail-vc0-f176.google.com with SMTP id lc6so7602844vcb.7 for ; Sun, 30 Mar 2014 19:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=8pr/clk+SLCLXw29u/do8t4eYYKkgyvdzOdX/s+1Lgs=; b=JwCAaItNr6Y+pMChoRxjKFO1JmPOHR5+NzbN4ycDyQz/KDo5Z0PpXIMxuXokWIRhns AiRzpJAG9YFXsOozrrV9htuHpS36URl1gNF0oJXIYWrUYzizfgZEz1dtPcS3FNwQpRiA Y/fLcI6Epjzy7kkGeamF0i1dw+3vXotkjeP5odCB8kYPCpgqQdBwtXI77HAjhTRMRVD/ Pmd3ZLTrbs3nB3pu0A2+LpZACe98bPXAztbXmYRn9N+dwLh10etlQMxwzRIQNa+C81hZ TB4d3TNt+V1NzNCH6bxJ5Yvwj13gVxlCCSYVTOLuvP2ySbvsA+6EPLpq7ZwY5dl9K/TO k3CQ== X-Received: by 10.220.12.66 with SMTP id w2mr20654214vcw.15.1396233077450; Sun, 30 Mar 2014 19:31:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.142.143 with HTTP; Sun, 30 Mar 2014 19:30:37 -0700 (PDT) From: Qiong Date: Mon, 31 Mar 2014 10:30:37 +0800 Message-ID: To: opsec@ietf.org Content-Type: multipart/alternative; boundary=001a11c315009aed1f04f5ddd871 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/SVo4uq4dJMPR5L-eh85EHbBbAUA Subject: [OPSEC] comments for firewall draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 02:31:22 -0000 --001a11c315009aed1f04f5ddd871 Content-Type: text/plain; charset=UTF-8 Hi authors, I recently read your draft draft-gont-opsec-ipv6-firewall-reqs-00 . I think it is quite useful for operators and it is in a good shape. Thanks for your effort. Just a quick question: I think NAT is a quite common function in firewall, is there some reason that it should not be included in IPv6 firewall ? Best wishes -- ============================================== Qiong Sun China Telecom Beijing Research Institute Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/ * PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --001a11c315009aed1f04f5ddd871 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi authors,

I recently read your draft= =C2=A0draft-gont-opsec-ipv6-firewall-reqs-00=C2=A0. I think it is qu= ite useful for operators and it is in a good shape. Thanks for your effort.=

Just a quick question: I think NAT is a quite common fu= nction in firewall, is there some reason that it should not be included in = IPv6 firewall ?

Best wishes=C2=A0

--=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Su= n
China Telecom Beijing Research Institute


Open source code:<= br>lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--001a11c315009aed1f04f5ddd871-- From nobody Mon Mar 31 00:54:06 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5041A08D1; Sun, 30 Mar 2014 13:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNM0mznfxLHK; Sun, 30 Mar 2014 13:42:06 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA411A07D7; Sun, 30 Mar 2014 13:42:05 -0700 (PDT) Received: from [198.252.137.115] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1WUMYD-000Osu-V7; Sun, 30 Mar 2014 16:41:53 -0400 Date: Sun, 30 Mar 2014 16:41:48 -0400 From: John C Klensin To: Andrew Sullivan , John Leslie Message-ID: In-Reply-To: <20140327234136.GC51988@mx1.yitter.info> References: <53349FFB.7050108@qti.qualcomm.com> <20140327233422.GD87785@verdi> <20140327234136.GC51988@mx1.yitter.info> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.115 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/20kFNpVJHbJB85rpXZeLIiDce7A X-Mailman-Approved-At: Mon, 31 Mar 2014 00:54:06 -0700 Cc: Pete Resnick , IETF Disgust , opsec wg mailing list , The IESG Subject: Re: [OPSEC] Saying no (was: Re: Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Mar 2014 20:42:08 -0000 --On Thursday, March 27, 2014 17:55 -0500 Pete Resnick wrote: > Oh, don't get me wrong. When I say "fix it", I don't mean that > they necessarily need to fix the protocol the approach. I > simply mean fix the document, which may amount to the WG > getting sufficient text in to say, "This is only useful in X Y > and Z circumstances and is otherwise a bad idea and you > shouldn't do it." We are happy to publish all sorts of > applicability statements that say, "This is stupid in all but > these circumstances." I just don't want the IESG to have to > write it up. The WG should make their document reflect what > the community wants. --On Thursday, March 27, 2014 19:41 -0400 Andrew Sullivan wrote: > On Thu, Mar 27, 2014 at 07:34:22PM -0400, John Leslie wrote: >> >> The sad truth is, the IESG no longer has the spare cycles >> to "Just say No." > > I was on the receiving end of an IESG that simply stalled a > document until the WG changed its approach, because of IETF > concerns, so I disagree with that claim. But if it is true, > then we might as well give up. If there's weak IETF consensus > (with some strong objections) to a document that comes from a > WG and has strong consensus inside the WG, the _only_ people > who can say no are the IESG; and they must. Hi. Two observations: (1) If the IESG were to ever reach the point that it doesn't have the cycles to properly evaluate community consensus about a document and to make sure that the document reflects that consensus before it is published, then they, and we, are in bad trouble. That is one or only two key parts of the IESG job (the other being WG oversight). If the IESG doesn't have the cycles do that that and still do anything else, then the "anything else" should go. If doing this type of work is still not possible, I'd expect to see the IESG giving serious consideration to procedural changes that would reduce their workload [1], reducing the number of WGs to what they can handle [2], or resigning in the hope that the Nomcom can find people with either the cycles or the willingness to make changes. (2) Like Pete, I strongly prefer getting a document to the point where it is consistent with community consensus by having the responsible WG and document editors make changes rather than using IESG statements. The latter should, IMO, be reserved for the most unusual situations if they are used at all. But the priority should be that we never publish an IETF-stream document, especially a standards track one, that doesn't reflect community consensus without its being very clear about that. (3) If a WG and the community run out of cycles to get a document right, then the document ought to be dead, especially if it is proposed for standards track. Too bad, but,... (4) Some of the notes in this thread -- and some IESG actions in the past-- have implied that at appropriate goal of the IESG review process is to find compromise positions that make everyone more or less happy. IMO, if we ever reach the point where we believe that, we will have given up everything that makes IETF standards superior to those of SDOs who believe that something produced by a WG, or even seriously proposed to one, is entitled to standardization. Our standards, and the Internet itself, work because we have focused on good, workable, solutions -- ideally with a minimum of options that could lead, intentionally or not, to lack of interoperability-- not compromises among ground who want "their" ideas standardized and the resulting "almost anything conforms" standards. john we should expect to see a lot of resignations (1) If we reach the point that either the IESG [1] (there has been no shortage of such proposals From nobody Mon Mar 31 03:17:03 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE93D1A0665; Mon, 31 Mar 2014 03:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.511 X-Spam-Level: X-Spam-Status: No, score=-9.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dep9dWowsJ2f; Mon, 31 Mar 2014 03:16:54 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 61A831A0661; Mon, 31 Mar 2014 03:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5256; q=dns/txt; s=iport; t=1396261011; x=1397470611; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=TOcQum6Zi2Yw/GvyxdDICRxcf8Q9Fkd5aAo1eKm7thw=; b=GIcfve4LvX/S93aGpVbEKJIDwy4DVvL6BEMRrDimS2EC7g86b5+pYVsO o6v3BtxLkdA9H7Qe8zLx+KPtJImfB+F5qIGRGvHd4zBQQO8wpGhkGIGtQ 6kzkE/sNBV0PFdcK6JlpGm3I4G4Ck91b5iWavWnz8E4jS2Cox+GzXP1fe 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigFAPc/OVOtJV2Z/2dsb2JhbABZgwY7V4MKuFiHNRmBAhZ0giUBAQEEAQEBIBE6BAcMBAIBCBEBAwEBAwIGGQQDAgICJQsUAQIGCAEBBAENBQiHcQ2uAqITEwSBKY0FAQEeBisHAgICgmk1gRQEqwOBcYE/gXI5 X-IronPort-AV: E=Sophos; i="4.97,764,1389744000"; d="scan'208,223"; a="31639196" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP; 31 Mar 2014 10:16:51 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s2VAGo8w007181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 10:16:50 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.114]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 31 Mar 2014 05:16:50 -0500 From: "Gunter Van de Velde (gvandeve)" To: "George, Wes" , Andrew Sullivan , John Leslie Thread-Topic: Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC Thread-Index: Ac9KgfWCg4ypupX+RKK9IVT6u5ttqgCR/hzw Date: Mon, 31 Mar 2014 10:16:50 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2411380416@xmb-aln-x12.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.83.21] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/oSDxu-GI4WybyF5wR1u7TcUVdnE Cc: Pete Resnick , opsec wg mailing list , IETF Disgust , The IESG Subject: Re: [OPSEC] Last Call: (Using Only Link-Local Addressing Inside an IPv6 Network) to Informational RFC X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 10:16:57 -0000 RnJvbSB0aGUgU2hlcGhlcmQgd3JpdGUtdXA6DQoNCig2KSBEZXNjcmliZSBhbnkgc3BlY2lmaWMg Y29uY2VybnMgb3IgaXNzdWVzIHRoYXQgdGhlIERvY3VtZW50IFNoZXBoZXJkDQpoYXMgd2l0aCB0 aGlzIGRvY3VtZW50IHRoYXQgdGhlIFJlc3BvbnNpYmxlIEFyZWEgRGlyZWN0b3IgYW5kL29yIHRo ZQ0KSUVTRyBzaG91bGQgYmUgYXdhcmUgb2Y/IEZvciBleGFtcGxlLCBwZXJoYXBzIGhlIG9yIHNo ZSBpcyB1bmNvbWZvcnRhYmxlDQp3aXRoIGNlcnRhaW4gcGFydHMgb2YgdGhlIGRvY3VtZW50LCBv ciBoYXMgY29uY2VybnMgd2hldGhlciB0aGVyZSByZWFsbHkNCmlzIGEgbmVlZCBmb3IgaXQuIElu IGFueSBldmVudCwgaWYgdGhlIFdHIGhhcyBkaXNjdXNzZWQgdGhvc2UgaXNzdWVzIGFuZA0KaGFz IGluZGljYXRlZCB0aGF0IGl0IHN0aWxsIHdpc2hlcyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwg ZGV0YWlsIHRob3NlDQpjb25jZXJucyBoZXJlLg0KDQo8U2hlcGhlcmQ+DQpJbiB0aGUgT1BTRUMg V0cgcGVvcGxlIGhhdmUgc3RhdGVkIHRoYXQgZXZlbnRob3VnaCB0aGV5IGRvIG5vdCBsaWtlIHRo ZSBMTEEgYXBwcm9hY2gsIHRoYXQgaGVyZSBpcyB2YWx1ZSBhbmQgc3VwcG9ydCBpbiBwdWJsaWNh dGlvbiBvZiB0aGUgYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcywgYmVjYXVzZSBwcm9wZXIg YWRkcmVzc2luZyBpcyBhIGtleSBuZXR3b3JrIGFyY2hpdGVjdHVyZSBxdWVzdGlvbi4gQXMgU2hl cGhlcmQgSSBzZWUgYSBuZWVkIGZvciBkb2N1bWVudGluZyB0aGlzIGluIGFuIElFVEYgZG9jdW1l bnQgYXMgaXQgaXMgYSBxdWVzdGlvbiB3aGVuIGFyY2hpdGVjdGluZyBhIE5ldHdvcmsuIA0KPC9T aGVwaGVyZD4NCg0KRy8NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT1BT RUMgW21haWx0bzpvcHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgR2VvcmdlLCBX ZXMNClNlbnQ6IDI4IE1hcmNoIDIwMTQgMTM6MzQNClRvOiBBbmRyZXcgU3VsbGl2YW47IEpvaG4g TGVzbGllDQpDYzogUGV0ZSBSZXNuaWNrOyBJRVRGIERpc2d1c3Q7IG9wc2VjIHdnIG1haWxpbmcg bGlzdDsgVGhlIElFU0cNClN1YmplY3Q6IFJlOiBbT1BTRUNdIExhc3QgQ2FsbDogPGRyYWZ0LWll dGYtb3BzZWMtbGxhLW9ubHktMDcudHh0PiAoVXNpbmcgT25seSBMaW5rLUxvY2FsIEFkZHJlc3Np bmcgSW5zaWRlIGFuIElQdjYgTmV0d29yaykgdG8gSW5mb3JtYXRpb25hbCBSRkMNCg0KT24gMy8y Ny8xNCwgNzo0MSBQTSwgIkFuZHJldyBTdWxsaXZhbiIgPGFqc0BhbnZpbHdhbHJ1c2Rlbi5jb20+ IHdyb3RlOg0KDQoNCj5JZiB0aGVyZSdzIHdlYWsgSUVURiBjb25zZW5zdXMgKHdpdGggc29tZSBz dHJvbmcgb2JqZWN0aW9ucykgdG8gYSANCj5kb2N1bWVudCB0aGF0IGNvbWVzIGZyb20gYSBXRyBh bmQgaGFzIHN0cm9uZyBjb25zZW5zdXMgaW5zaWRlIHRoZSBXRywNCg0KUmVzdG9yaW5nIHN1Ympl Y3QgbGluZSwgYXMgbXkgY29tbWVudCBpcyBtb3JlIHNwZWNpZmljIHRvIHRoZSBkcmFmdCwgbm90 IGdlbmVyYWxseSBhYm91dCDigJxzYXlpbmcgbm/igJ0sIGJ1dCB0aGUgY29tbWVudCBtYWRlIG1l IHdvbmRlciBhYm91dCB0aGUgbGV2ZWwgb2YgY29uc2Vuc3VzLg0KSeKAmWxsIGxldCB0aGUgY2hh aXJzIHNwZWFrIGZvciB0aGVtc2VsdmVzIGFzIHRvIGhvdyB0aGV5IG1hZGUgdGhlIGRldGVybWlu YXRpb24gdGhhdCBpdCB3YXMgYWNjZXB0YWJsZSB0byBwcm9jZWVkLCBhbmQgc2ltaWxhcmx5IGF0 IFdHIGFkb3B0aW9uIGNhbGwsIGJ1dCBpbiBsb29raW5nIGJhY2sgYXQgdGhlIE9wU2VjIGxpc3Qg YXJjaGl2ZXMgdG8gd3JpdGUgdGhpcyBtZXNzYWdlLCBJIGRvbuKAmXQgdmlldyB0aGlzIGFzIGhh dmluZyBwYXJ0aWN1bGFybHkgc3Ryb25nIGNvbnNlbnN1cyB3aXRoaW4gdGhlIFdHIHRvIHB1Ymxp c2guIFRoZSBhZG9wdGlvbiBjYWxsIFsxXSB3YXMg4oCcbm8gb2JqZWN0aW9u4oCdIGFuZCB3aGls ZSBJIHNlZSByZXZpZXdzIGF0IGFkb3B0aW9uIGNhbGwsIEkgc2VlIG5vIHN0cm9uZyBtZXNzYWdl cyBvZiBzdXBwb3J0DQoqb3IqIG9wcG9zaXRpb24uIFRoZSBXR0xDIHdhcyBhY3R1YWxseSBjb21w bGV0ZWQgb24gdmVyc2lvbiAtMDMsIGluIE1hcmNoIG9mICoyMDEzKiBbMl0uIFRoZSBkcmFmdCBp cyBub3cgdmVyc2lvbiAtMDcsIGFuZCBubyBuZXcgV0dMQyB3YXMgZG9uZS4gVGhlIHJldmlld3Mg ZG9uZSBhdCBXR0xDIGxvb2sgdG8gbWUgbGlrZSB0aGVyZSB3ZXJlIDMgb3IgNCBpbiB0b3RhbCwg b25lIG9mIHdoaWNoIChtaW5lKSBleHByZXNzZWQgY29uY2VybnMgYWJvdXQgdGhlIGRvY3VtZW50 IHByb2NlZWRpbmcgKHRoZSBtZXNzYWdlIGlzIHJlZmVyZW5jZWQgaW4gbXkgcHJldmlvdXMgbWVz c2FnZSksIHRoZSBvdGhlcnMgbWFpbmx5IGZvY3VzZWQgb24gdGhlIGRvY3VtZW504oCZcyBjb21w bGV0ZW5lc3MgYW5kIGFjY3VyYWN5LCBub3Qgd2hldGhlciBpdCB3YXMgYSBnb29kIG9yIGJhZCBp ZGVhLg0KDQpMaWtlIEpvZWwsIEnigJltIG5vdCB3aWxsaW5nIHRvIGdvIHRvIHRoZSB3YWxsIChJ LmUuIEFwcGVhbCBvbiBwcm9jZXNzDQpncm91bmRzKSB0byBwcmV2ZW50IHRoaXMgZHJhZnQgZnJv bSBiZWluZyBwdWJsaXNoZWQsIGJ1dCBJIHRob3VnaHQgdGhhdCB0aGlzIGluZm9ybWF0aW9uIG1p Z2h0IGJlIGhlbHBmdWwgaW4gZGV0ZXJtaW5pbmcgaG93IHRvIHByb2NlZWQuDQoNCldlcyBHZW9y Z2UNCg0KWzFdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvb3BzZWMvc0hu bjUybFk4dGlrOVFqVkpjeVV2R01vRTU4DQpbMl0gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy9vcHNlYy9NVTVFLWpnelN1Z043ZzJrU1g3NDB0aW5FVmsNCg0KQW55dGhpbmcg YmVsb3cgdGhpcyBsaW5lIGhhcyBiZWVuIGFkZGVkIGJ5IG15IGNvbXBhbnnigJlzIG1haWwgc2Vy dmVyLCBJIGhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQoNClRoaXMg RS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVy IENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5l ciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVy ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWlu Zywgb3IgYWN0aW9uIHRha2VuIGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0 YWNobWVudHMgdG8gdGhpcyBFLW1haWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJl IHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUg dGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0 Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9QU0VD IG1haWxpbmcgbGlzdA0KT1BTRUNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vb3BzZWMNCg== From nobody Mon Mar 31 04:34:49 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 454F01A0704 for ; Mon, 31 Mar 2014 04:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.425 X-Spam-Level: * X-Spam-Status: No, score=1.425 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5c7yfCVMJDJc for ; Mon, 31 Mar 2014 04:34:44 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 579F11A06EF for ; Mon, 31 Mar 2014 04:34:44 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,764,1389762000"; d="scan'208,217";a="255543953" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 31 Mar 2014 07:33:24 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Mon, 31 Mar 2014 07:34:40 -0400 From: "George, Wes" To: Qiong , "opsec@ietf.org" Date: Mon, 31 Mar 2014 07:34:39 -0400 Thread-Topic: [OPSEC] comments for firewall draft Thread-Index: Ac9M1TQGAYGioS6hQN2WWE0R2MpyUQ== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CF5EC8E616B7Fwesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/6Fv9ujgUtNvrZeI4iCFBG5ypW_w Subject: Re: [OPSEC] comments for firewall draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 11:34:46 -0000 --_000_CF5EC8E616B7Fwesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBRaW9uZyA8YmluZ3h1ZXJlQGdtYWlsLmNvbTxtYWlsdG86YmluZ3h1ZXJlQGdtYWls LmNvbT4+DQoNCg0KSnVzdCBhIHF1aWNrIHF1ZXN0aW9uOiBJIHRoaW5rIE5BVCBpcyBhIHF1aXRl IGNvbW1vbiBmdW5jdGlvbiBpbiBmaXJld2FsbCwgaXMgdGhlcmUgc29tZSByZWFzb24gdGhhdCBp dCBzaG91bGQgbm90IGJlIGluY2x1ZGVkIGluIElQdjYgZmlyZXdhbGwgPw0KDQpXR10gQmVjYXVz ZSBOQVQgc2hvdWxkIG5vdCBiZSB1c2VkIHVubGVzcyBuZWNlc3NhcnkuIE5BVCBpcyBvZnRlbiBj b25mdXNlZCB3aXRoIHNlY3VyaXR5IChpLmUuIHNlY3VyaXR5IGJ5IG9ic2N1cml0eSksIGJ1dCB3 ZeKAmXJlIHJlYWxseSB0cnlpbmcgdG8gYnJlYWsgdGhhdCBjb25mbGF0aW9uIGluIElQdjYgc2lu Y2UgaXQgaXMgYWxzbyBub3QgbmVjZXNzYXJ5IGZvciBhZGRyZXNzIHByZXNlcnZhdGlvbiBhbmQg cmVhbGx5IHNob3VsZG7igJl0IGJlIHVzZWQgZm9yIGV2ZW4gMToxIGFkZHJlc3MgdHJhbnNsYXRp b24gc2luY2UgaXQgaXMgcG9zc2libGUgdG8gYWRkIG11bHRpcGxlIGFkZHJlc3NlcyBmb3IgaG9z dHMsIHNvIHRoYXQgdGhleSBjYW4gaGF2ZSBhZGRyZXNzZXMgZm9yIGJvdGggaW50ZXJuYWwgYW5k IGV4dGVybmFsIHNjb3BlLCByYXRoZXIgdGhhbiB0aGUgZXhpc3RpbmcgcHJpdmF0ZS9wdWJsaWMg TkFUIHRoYXQgaGFwcGVucyBpbiBtYW55IG5ldHdvcmtzIHRvZGF5IG9uIElQdjQuDQoNClNvIGlm IGFueXRoaW5nLCB0aGUgZG9jdW1lbnQgcHJvYmFibHkgbmVlZHMgd29yZHMgdG8gdGhhdCBlZmZl Y3Qgc28gdGhhdCBpdOKAmXMgZXhwbGljaXRseSBjbGVhciB0aGF0IHRoaXMgaXMgYSBub24gcmVx dWlyZW1lbnQuDQoNCldlcyBHZW9yZ2UNCg0KQW55dGhpbmcgYmVsb3cgdGhpcyBsaW5lIGhhcyBi ZWVuIGFkZGVkIGJ5IG15IGNvbXBhbnnigJlzIG1haWwgc2VydmVyLCBJIGhhdmUgbm8gY29udHJv bCBvdmVyIGl0Lg0KLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g VGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZp bGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRv IFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3Nl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwg eW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRz IG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk IGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVu dGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBh bnkgcHJpbnRvdXQuDQo= --_000_CF5EC8E616B7Fwesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5RaW9uZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJpbmd4 dWVyZUBnbWFpbC5jb20iPmJpbmd4dWVyZUBnbWFpbC5jb208L2E+Jmd0OzwvZGl2Pg0KPC9zcGFu Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8 ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGln bjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1M RUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47 IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRF Ui1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPGJyPg0KPC9kaXY+DQo8 ZGl2IGRpcj0ibHRyIj4NCjxkaXY+SnVzdCBhIHF1aWNrIHF1ZXN0aW9uOiBJIHRoaW5rIE5BVCBp cyBhIHF1aXRlIGNvbW1vbiBmdW5jdGlvbiBpbiBmaXJld2FsbCwgaXMgdGhlcmUgc29tZSByZWFz b24gdGhhdCBpdCBzaG91bGQgbm90IGJlIGluY2x1ZGVkIGluIElQdjYgZmlyZXdhbGwgPzwvZGl2 Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V0ddIEJlY2F1c2UgTkFUIHNob3VsZCBub3QgYmUg dXNlZCB1bmxlc3MgbmVjZXNzYXJ5LiBOQVQgaXMgb2Z0ZW4gY29uZnVzZWQgd2l0aCBzZWN1cml0 eSAoaS5lLiBzZWN1cml0eSBieSBvYnNjdXJpdHkpLCBidXQgd2XigJlyZSByZWFsbHkgdHJ5aW5n IHRvIGJyZWFrIHRoYXQgY29uZmxhdGlvbiBpbiBJUHY2IHNpbmNlIGl0IGlzIGFsc28gbm90IG5l Y2Vzc2FyeSBmb3IgYWRkcmVzcyBwcmVzZXJ2YXRpb24gYW5kIHJlYWxseSBzaG91bGRu4oCZdA0K IGJlIHVzZWQgZm9yIGV2ZW4gMToxIGFkZHJlc3MgdHJhbnNsYXRpb24gc2luY2UgaXQgaXMgcG9z c2libGUgdG8gYWRkIG11bHRpcGxlIGFkZHJlc3NlcyBmb3IgaG9zdHMsIHNvIHRoYXQgdGhleSBj YW4gaGF2ZSBhZGRyZXNzZXMgZm9yIGJvdGggaW50ZXJuYWwgYW5kIGV4dGVybmFsIHNjb3BlLCBy YXRoZXIgdGhhbiB0aGUgZXhpc3RpbmcgcHJpdmF0ZS9wdWJsaWMgTkFUIHRoYXQgaGFwcGVucyBp biBtYW55IG5ldHdvcmtzIHRvZGF5IG9uIElQdjQuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvc3Bh bj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlNvIGlmIGFueXRoaW5nLCB0aGUgZG9jdW1lbnQg cHJvYmFibHkgbmVlZHMgd29yZHMgdG8gdGhhdCBlZmZlY3Qgc28gdGhhdCBpdOKAmXMgZXhwbGlj aXRseSBjbGVhciB0aGF0IHRoaXMgaXMgYSBub24gcmVxdWlyZW1lbnQuPC9kaXY+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5XZXMgR2VvcmdlPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDEyNywgMTI3LCAxMjcpOyBm b250LXNpemU6IDExcHQ7Ij5Bbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQg YnkgbXkgY29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkgaGF2ZSBubyBjb250cm9sIG92ZXIgaXQu PC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxzcGFuIHN0eWxlPSJjb2xvcjog cmdiKDEyNywgMTI3LCAxMjcpOyI+LS0tLS0tLS0tLS08L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigxMjcsIDEyNywgMTI3KTsi Pjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xv cj0iR3JheSIgc2l6ZT0iMSI+VGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdo aWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQg YmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBz b2xlbHkNCiBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2gg aXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9m IHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0 aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0 byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvDQogdGhpcyBFLW1haWwgaXMgc3Ry aWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0 ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkgY29weSBvZiB0 aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Ljxicj4NCjwvZm9udD4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_CF5EC8E616B7Fwesleygeorgetwcablecom_-- From nobody Mon Mar 31 08:56:34 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F711A6F5B for ; Mon, 31 Mar 2014 08:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEmrtoDwlqSq for ; Mon, 31 Mar 2014 08:56:30 -0700 (PDT) Received: from sudnp799.qwest.com (sudnp799.qwest.com [155.70.32.99]) by ietfa.amsl.com (Postfix) with ESMTP id B72AC1A6F59 for ; Mon, 31 Mar 2014 08:56:30 -0700 (PDT) Received: from lxdenvmpc030.qintra.com (lxdenvmpc030.qintra.com [10.1.51.30]) by sudnp799.qwest.com (8.14.4/8.14.4) with ESMTP id s2VFuQ0B007233 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Mar 2014 09:56:27 -0600 (MDT) Received: from lxdenvmpc030.qintra.com (unknown [127.0.0.1]) by IMSA (Postfix) with ESMTP id B580E1E006C; Mon, 31 Mar 2014 09:56:21 -0600 (MDT) Received: from sudnp796.qintra.com (unknown [151.119.91.93]) by lxdenvmpc030.qintra.com (Postfix) with ESMTP id 873D91E0085; Mon, 31 Mar 2014 09:56:21 -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 s2VFuLkE020746; Mon, 31 Mar 2014 09:56:21 -0600 (MDT) Received: from vddcwhubex502.ctl.intranet (vddcwhubex502.ctl.intranet [151.119.128.29]) by sudnp796.qintra.com (8.14.4/8.14.4) with ESMTP id s2VFuKYr020716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Mar 2014 09:56:21 -0600 (MDT) Received: from PDDCWMBXEX503.ctl.intranet ([fe80::9033:ef22:df02:32a9]) by vddcwhubex502.ctl.intranet ([2002:9777:801d::9777:801d]) with mapi id 14.03.0158.001; Mon, 31 Mar 2014 09:56:20 -0600 From: "Smith, Donald" To: "George, Wes" , Qiong , "opsec@ietf.org" Thread-Topic: [OPSEC] comments for firewall draft Thread-Index: AQHPTIlQYjv272EFL0Kh1dI1w5IkF5r7demA///g3sQ= Date: Mon, 31 Mar 2014 15:56:19 +0000 Message-ID: <68EFACB32CF4464298EA2779B058889D1244F90B@PDDCWMBXEX503.ctl.intranet> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [151.119.128.7] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/LUEomjX_woaQOcaI-DbpOXRAklw Subject: Re: [OPSEC] comments for firewall draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 15:56:32 -0000 Why does everyone believe NAT (NAPT really) is security by obscurity? For the port translation portion it makes it harder, 64k harder, to find th= e open ports (ok really less then 32k harder due to the birthday paradox bu= t still). SRC based NAT meets the intent of bcp38 by preventing src based ip address = spoofing. We (collectively) have millions of broadband customers that can'= t do src based IP address spoofing due to NAT.=20 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: OPSEC [opsec-bounces@ietf.org] on behalf of George, Wes [wesley.georg= e@twcable.com] Sent: Monday, March 31, 2014 5:34 AM To: Qiong; opsec@ietf.org Subject: Re: [OPSEC] comments for firewall draft From: Qiong Just a quick question: I think NAT is a quite common function in firewall, = is there some reason that it should not be included in IPv6 firewall ? WG] Because NAT should not be used unless necessary. NAT is often confused = with security (i.e. security by obscurity), but we=92re really trying to br= eak that conflation in IPv6 since it is also not necessary for address pres= ervation and really shouldn=92t be used for even 1:1 address translation si= nce it is possible to add multiple addresses for hosts, so that they can ha= ve addresses for both internal and external scope, rather than the existing= private/public NAT that happens in many networks today on IPv4.=20 So if anything, the document probably needs words to that effect so that it= =92s explicitly clear that this is a non requirement. Wes George Anything below this line has been added by my company=92s mail server, I ha= ve no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.= From nobody Mon Mar 31 09:27:34 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1321A0893 for ; Mon, 31 Mar 2014 09:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrfPGQiqZt6H for ; Mon, 31 Mar 2014 09:27:27 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.15]) by ietfa.amsl.com (Postfix) with ESMTP id DA7991A088C for ; Mon, 31 Mar 2014 09:27:27 -0700 (PDT) Received: from [216.82.250.83:38542] by server-15.bemta-12.messagelabs.com id 5E/B8-00481-C6799335; Mon, 31 Mar 2014 16:27:24 +0000 X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1396283243!3887696!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=resmed.com,-,- X-VirusChecked: Checked Received: (qmail 12393 invoked from network); 31 Mar 2014 16:27:24 -0000 Received: from unknown (HELO mail.resmed.de) (195.234.33.10) by server-7.tower-120.messagelabs.com with SMTP; 31 Mar 2014 16:27:24 -0000 Received: from GE2EML2K1001.corp.resmed.org ([172.17.6.115]) by mail.resmed.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Mar 2014 18:27:23 +0200 Received: from GE2EML2K1003.corp.resmed.org ([fe80::8547:a85:1c2d:a4bd]) by GE2EML2K1001.corp.resmed.org ([fe80::d04f:a66e:be79:d90a%21]) with mapi id 14.01.0218.012; Mon, 31 Mar 2014 18:27:23 +0200 From: Marco Ermini To: "Smith, Donald" , "George, Wes" , Qiong , "opsec@ietf.org" Thread-Topic: [OPSEC] comments for firewall draft Thread-Index: AQHPTIlWpyXEukspEkWNz7BwNWd4kZr678yAgABJHICAACjbsA== Date: Mon, 31 Mar 2014 16:27:22 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C46A14199@GE2EML2K1003.corp.resmed.org> References: , <68EFACB32CF4464298EA2779B058889D1244F90B@PDDCWMBXEX503.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D1244F90B@PDDCWMBXEX503.ctl.intranet> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.87] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Mar 2014 16:27:23.0511 (UTC) FILETIME=[1898E070:01CF4CFE] Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/8xYsthPpdWdh0d8bDkBrrSQqtgg Subject: Re: [OPSEC] comments for firewall draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:27:30 -0000 Hi, I think this is a good point, and I personally agree with all of the comme= nts. NAT is pretty common in firewalls, and things such as NAT64 or NAT46 (or a= ny combination of 4s and 6s...) are pretty commonly used, therefore they s= hould be present, especially in the context of carrier-grade NAT for IPv6 = providers. I'll take some time to talk with the co-authors about this. Marco Ermini Senior IT Security and Compliance Analyst =20 ResMed Germany Inc=A0Fraunhofer Str. 16 - 82152 - Martinsried - Germany ResMed.com -----Original Message----- From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Smith, Donald Sent: Monday, March 31, 2014 5:56 PM To: George, Wes; Qiong; opsec@ietf.org Subject: Re: [OPSEC] comments for firewall draft Why does everyone believe NAT (NAPT really) is security by obscurity? For the port translation portion it makes it harder, 64k harder, to find t= he open ports (ok really less then 32k harder due to the birthday paradox = but still). SRC based NAT meets the intent of bcp38=20by preventing src based ip addre= ss spoofing. We (collectively) have millions of broadband customers that = can't do src based IP address spoofing due to NAT.=20 (coffee !=3D sleep) & (!coffee =3D=3D sleep) Donald.Smith@centurylink.com From: OPSEC [opsec-bounces@ietf.org] on behalf of George, Wes [wesley.geor= ge@twcable.com] Sent: Monday, March 31, 2014 5:34 AM To: Qiong; opsec@ietf.org Subject: Re: [OPSEC] comments for firewall draft From: Qiong Just a quick question: I think NAT is a quite common function in firewall,= is there some reason that it should not be included in IPv6 firewall ? WG] Because NAT should not be used unless necessary. NAT is often confused= with security (i.e. security by obscurity), but we're really trying to br= eak that conflation in IPv6 since it is also not necessary for address pre= servation and really shouldn't be used for even 1:1 address translation si= nce it is possible to add multiple addresses for hosts, so that they can h= ave addresses for both internal and external scope, rather than the existi= ng private/public NAT that happens in many networks today on IPv4.=20 So if anything, the document probably needs words to that effect so that i= t's explicitly clear that this is a non requirement. Wes George Anything below this line has been added by my company's mail server, I hav= e no control over it. ----------- This E-mail and any of its attachments may contain Time Warner Cable propr= ietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for th= e use of the individual or entity to which it is addressed. If you are not= the intended recipient of this E-mail, you are hereby notified that any d= issemination, distribution, copying, or action taken in relation to the co= ntents of and attachments to this E-mail is strictly prohibited and may be= unlawful. If you have received this E-mail in error, please notify the se= nder immediately and permanently delete the original and any=20copy of thi= s E-mail and any printout. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec ---------------------------------------------------------------------- Warning: Copyright ResMed. Where the contents of this email and/or attac= hment includes materials prepared by ResMed, the use of those materials is subject exclusively to the conditions of engagement between R= esMed and the intended recipient. This communication is confidential and = may contain legally privileged information. By the use of email over the = Internet or other communication systems, ResMed is not waiving either conf= identiality of, or legal privilege in, the content of the email and of any= attachments. If the recipient of this message is not the intended addres= see, please call ResMed immediately on 1 (800) 424-0737 USA. ---------------------------------------------------------------------- From nobody Mon Mar 31 09:52:50 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965601A0897 for ; Mon, 31 Mar 2014 09:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBph_CKHRhKJ for ; Mon, 31 Mar 2014 09:52:47 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 002391A0895 for ; Mon, 31 Mar 2014 09:52:46 -0700 (PDT) Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:59:db2b:61af:a63c]) by jazz.viagenie.ca (Postfix) with ESMTPSA id BC3F04006B for ; Mon, 31 Mar 2014 12:52:42 -0400 (EDT) Message-ID: <53399D5A.8050802@viagenie.ca> Date: Mon, 31 Mar 2014 12:52:42 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: opsec@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/CES1hkimO53d8AbI56InvbbqiTo Subject: Re: [OPSEC] comments for firewall draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:52:48 -0000 Le 2014-03-30 22:30, Qiong a écrit : > I think NAT is a quite common function in firewall, is there some > reason that it should not be included in IPv6 firewall ? Do you have specific things in mind that the draft should say on this topic? IMHO, the fact that NAT is common in firewall equipment is irrelevant. Many other functions are common: IPSEC gateway, SSL VPN, IDS, etc. etc. etc. A draft covering everything would be a huge effort with low chance of success. I would prefer this draft to remain focused on the core firewall function. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From nobody Mon Mar 31 10:35:53 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2922A1A07C3 for ; Mon, 31 Mar 2014 10:35:50 -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=-1.9, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na24sSi0QNcG for ; Mon, 31 Mar 2014 10:35:48 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.106]) by ietfa.amsl.com (Postfix) with ESMTP id 260781A6F05 for ; Mon, 31 Mar 2014 10:35:46 -0700 (PDT) Received: from [216.82.253.163:56522] by server-10.bemta-7.messagelabs.com id B6/08-11882-E67A9335; Mon, 31 Mar 2014 17:35:42 +0000 X-Env-Sender: Marco.Ermini@ResMed.com X-Msg-Ref: server-4.tower-166.messagelabs.com!1396287341!13133420!1 X-Originating-IP: [195.234.33.10] X-StarScan-Received: X-StarScan-Version: 6.11.1; banners=resmed.com,-,- X-VirusChecked: Checked Received: (qmail 14069 invoked from network); 31 Mar 2014 17:35:42 -0000 Received: from unknown (HELO mail.resmed.de) (195.234.33.10) by server-4.tower-166.messagelabs.com with SMTP; 31 Mar 2014 17:35:42 -0000 Received: from GE2EML2K1002.corp.resmed.org ([172.17.6.117]) by mail.resmed.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Mar 2014 19:35:41 +0200 Received: from GE2EML2K1003.corp.resmed.org ([fe80::8547:a85:1c2d:a4bd]) by GE2EML2K1002.corp.resmed.org ([fe80::f03c:7713:9fd9:8984%17]) with mapi id 14.01.0355.002; Mon, 31 Mar 2014 19:35:40 +0200 From: Marco Ermini To: "opsec@ietf.org" Thread-Topic: [OPSEC] comments for firewall draft Thread-Index: AQHPTIlWpyXEukspEkWNz7BwNWd4kZr7SKkAgAAqYWA= Date: Mon, 31 Mar 2014 17:35:40 +0000 Message-ID: <38465846B6383D4A8688C0A13971900C46A146D7@GE2EML2K1003.corp.resmed.org> References: <53399D5A.8050802@viagenie.ca> In-Reply-To: <53399D5A.8050802@viagenie.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.48.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 31 Mar 2014 17:35:41.0205 (UTC) FILETIME=[A3035C50:01CF4D07] Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/TpLE91EWwWL9tEMp8SclHsKTQH4 Subject: Re: [OPSEC] comments for firewall draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 17:35:50 -0000 -----Original Message----- From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Simon Perreault Sent: Monday, March 31, 2014 6:53 PM To: opsec@ietf.org Subject: Re: [OPSEC] comments for firewall draft > Do you have specific things in mind that the draft should say on this to= pic? > > IMHO, the fact that NAT is common in firewall equipment is irrelevant. > Many other functions are common: IPSEC gateway, SSL VPN, IDS, etc. etc. > etc. A draft covering everything would be a huge effort with low chance = of success. > > I would prefer this draft to remain focused on the core firewall functio= n. Well, then the argument is: is NAT a central function in a firewall, espec= ially in an IPv6 one? I do believe NAT is a bit different than the others you mentioned, because= in the great majority of circumstances you would really use a firewall to= perform NAT. In all of the other cases you mentioned (VPN, NIDS, etc.) they may be enab= led with a license in environments where no better solution is desired, re= quired or could be afforded; but they are really not central to a firewall= , and are better performed with a dedicated system. Mileage may vary with different firewall brands; e.g. with Juniper, SSL VP= N is better provided by a dedicated security gateway appliance, while in C= isco or Palo Alto there is more convergence and this function is enabled b= y license. Anyway, all of them (thinking especially about NIDS/NIPS) are b= etter provided by dedicated appliances and are not really so central for a= firewall. Worth to be noted, in the original RFP document I redacted, there were als= o all of these functions, but they were removed as it would have been too = many things to discuss at once. However, I do think that NAT may have some= special merit. Therefore it would be good to collect votes on that. So fa= r I got 3+ and 1- if I am not wrong. Marco Ermini=20 Senior IT Security and Compliance Analyst ResMed Germany Inc Fraunhofer Str. 16 - 82152 - Martinsried - Germany =20 ResMed.com=20 ---------------------------------------------------------------------- Warning: Copyright ResMed. Where the contents of this email and/or attac= hment includes materials prepared by ResMed, the use of those materials is subject exclusively to the conditions of engagement between R= esMed and the intended recipient. This communication is confidential and = may contain legally privileged information. By the use of email over the = Internet or other communication systems, ResMed is not waiving either conf= identiality of, or legal privilege in, the content of the email and of any= attachments. If the recipient of this message is not the intended addres= see, please call ResMed immediately on 1 (800) 424-0737 USA. ---------------------------------------------------------------------- From nobody Mon Mar 31 12:17:17 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF5B1A08BE for ; Mon, 31 Mar 2014 12:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.475 X-Spam-Level: X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRbLkildKHV3 for ; Mon, 31 Mar 2014 12:17:10 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 7D08F1A08B4 for ; Mon, 31 Mar 2014 12:17:10 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.97,767,1389762000"; d="scan'208";a="255996791" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 31 Mar 2014 15:15:43 -0400 Received: from PRVPEXVS15.corp.twcable.com ([10.136.163.78]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Mon, 31 Mar 2014 15:16:42 -0400 From: "George, Wes" To: "Smith, Donald" , Qiong , "opsec@ietf.org" Date: Mon, 31 Mar 2014 15:16:41 -0400 Thread-Topic: [OPSEC] comments for firewall draft Thread-Index: Ac9NFb/CEGJuaUvxTA+uT+1ZgPxAxg== Message-ID: References: <68EFACB32CF4464298EA2779B058889D1244F90B@PDDCWMBXEX503.ctl.intranet> In-Reply-To: <68EFACB32CF4464298EA2779B058889D1244F90B@PDDCWMBXEX503.ctl.intranet> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/xssBOyQQ3O0nkh3qQugx1QvWjbI Subject: Re: [OPSEC] comments for firewall draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 19:17:12 -0000 T24gMy8zMS8xNCwgMTE6NTYgQU0sICJTbWl0aCwgRG9uYWxkIiA8RG9uYWxkLlNtaXRoQENlbnR1 cnlMaW5rLmNvbT4gd3JvdGU6DQoNCg0KPldoeSBkb2VzIGV2ZXJ5b25lIGJlbGlldmUgTkFUIChO QVBUIHJlYWxseSkgaXMgc2VjdXJpdHkgYnkgb2JzY3VyaXR5Pw0KPkZvciB0aGUgcG9ydCB0cmFu c2xhdGlvbiBwb3J0aW9uIGl0IG1ha2VzIGl0IGhhcmRlciwgNjRrIGhhcmRlciwgdG8gZmluZA0K PnRoZSBvcGVuIHBvcnRzIChvayByZWFsbHkgbGVzcyB0aGVuIDMyayBoYXJkZXIgZHVlIHRvIHRo ZSBiaXJ0aGRheQ0KPnBhcmFkb3ggYnV0IHN0aWxsKS4NCldHXSBJTU8g4oCcaGFyZGVyIHRvIGF0 dGFjayBiZWNhdXNlIGhhcmRlciB0byBmaW5k4oCdIGlzIHByZXR0eSBtdWNoIHRoZQ0KZGVmaW5p dGlvbiBvZiBzZWN1cml0eSBieSBvYnNjdXJpdHkuIFRoYXTigJlzIG5vdCB0byBzYXkgdGhhdCBz ZWN1cml0eSBieQ0Kb2JzY3VyaXR5IGFkZHMgbm8gdmFsdWUsIGJ1dCBJIGRvbuKAmXQgYmVsaWV2 ZSB0aGF0IGl04oCZcyBvZiBzdWNoIGhpZ2ggdmFsdWUNCnRoYXQgaXQgY2Fu4oCZdCBiZSByZXBs YWNlZCB3aXRoIG90aGVyIHRoaW5ncy4gSW4gb3RoZXIgd29yZHMsIGl04oCZcyBub3QgYW4NCmlt bXV0YWJsZSByZXF1aXJlbWVudCBmb3IgcHJvcGVyIHNlY3VyaXR5Lg0KDQo+U1JDIGJhc2VkIE5B VCBtZWV0cyB0aGUgaW50ZW50IG9mIGJjcDM4IGJ5IHByZXZlbnRpbmcgc3JjIGJhc2VkIGlwDQo+ YWRkcmVzcyBzcG9vZmluZy4gV2UgKGNvbGxlY3RpdmVseSkgIGhhdmUgbWlsbGlvbnMgb2YgYnJv YWRiYW5kIGN1c3RvbWVycw0KPnRoYXQgY2FuJ3QgZG8gc3JjIGJhc2VkIElQIGFkZHJlc3Mgc3Bv b2ZpbmcgZHVlIHRvIE5BVC4NCldHXSBUaGF0IGNlcnRhaW5seSBtYWtlcyBzZW5zZSwgYnV0IGlm IHRoYXQgd2VyZSBjb25zaXN0ZW50bHkgdHJ1ZSwNCnRoZXJl4oCZZCBiZSBubyByZWFzb24gdG8g aW1wbGVtZW50IHVSUEYgb24gRFNMQU1zIG9yIENNVFNzLCBhbmQgd2UgbGlrZWx5DQp3b3VsZG7i gJl0IGhhdmUgdGhlIHByb2JsZW0gd2UgaGF2ZSB0b2RheSB3aXRoIHNwb29mZWQgdHJhZmZpYyBj b21pbmcgZnJvbQ0KYWxsIG92ZXIsIGdpdmVuIHRoZSBwcmV2YWxlbmNlIG9mIE5BVHMgaW4gcmVz aWRlbnRpYWwgYW5kIGVudGVycHJpc2UNCm5ldHdvcmtzLiBJIGhhdmUgdHJvdWJsZSBleHBsYWlu aW5nIHRoZSBleGlzdGVuY2Ugb2YgdGhlIGFtb3VudCBvZiBzcG9vZmVkDQp0cmFmZmljIHRoYXQg d2Ugc2VlbSB0byBiZSBmaWdodGluZyB3aXRoIHRvZGF5IGFzIG9yaWdpbmF0aW5nIHNvbGVseSBm cm9tDQpkZXZpY2VzIHRoYXQgYXJlIGRpcmVjdGx5IGNvbm5lY3RlZCB3aXRob3V0IGFueSBOQVQg aW4gZnJvbnQgb2YgdGhlbS4gSQ0KdGhpbmsgdGhlIHJlYWxpdHkgaXMgdGhhdCB0aGVyZSBhcmUg cGxlbnR5IG9mIE5BVCBib3hlcyB0aGF0IHdpbGwgaGFwcGlseQ0KcGFzcyBhbGwgc29ydHMgb2Yg anVuayB1cHN0cmVhbSwgYW5kIE1BWUJFIGlmIHRoZXnigJlyZSBzbWFydCB0aGV54oCZbGwgb25s eQ0KdHJ5IHRvIE5BVCBzdHVmZiBzb3VyY2VkIGZyb20gdGhlaXIgaW50ZXJuYWwgTEFOIGFuZCBz aW1wbHkgcGFzcyB0aGUgb3RoZXINCnN0dWZmIHVubW9sZXN0ZWQuDQoNCk15IHBvaW50IGlzIHRo YXQganVzdGlmeWluZyAob3Igd29yc2UsIFJFUVVJUklORykgTkFUIGluIGEgZmlyZXdhbGwNCmJl Y2F1c2UgaXQgZ2l2ZXMgeW91IEJDUDM4IG9yIHNlY3VyaXR5IGJ5IG9ic2N1cml0eSBpcyBzb2x2 aW5nIGZvciB0aGUNCndyb25nIHRoaW5nIGFuZCBjb25mbGF0aW5nIHRoZSBwcmltYXJ5IHB1cnBv c2Ugb2YgTkFUIChhZGRyZXNzDQpzaGFyaW5nL3Jld3JpdGluZykgd2l0aCBzb21lIG9mIHRoZSBh cmd1YWJseSBoZWxwZnVsIHNpZGUgZWZmZWN0cyBvZiB1c2luZw0KaXQuIFByZXZlbnRpbmcgc3Bv b2ZlZCB0cmFmZmljLCBhbmQgcHJvdmlkaW5nIHByb3BlciBzZWN1cml0eSBpcyBhIGdvb2QNCmdv YWwuIFRoZXJlIGFyZSBvdGhlciB3YXlzIHRvIGdldCB0aGVyZSBiZXNpZGVzIE5BVC4NCg0KV2Vz IEdlb3JnZQ0KDQpBbnl0aGluZyBiZWxvdyB0aGlzIGxpbmUgaGFzIGJlZW4gYWRkZWQgYnkgbXkg Y29tcGFueeKAmXMgbWFpbCBzZXJ2ZXIsIEkNCmhhdmUgbm8gY29udHJvbCBvdmVyIGl0Lg0KLS0t LS0tLS0tLS0NCg0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2gg aXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxv bmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMg YWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMg RS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBk aXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUg Y29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBF LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1h aWwgYW5kIGFueSBwcmludG91dC4NCg== From nobody Mon Mar 31 13:54:45 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC881A7026 for ; Mon, 31 Mar 2014 13:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TrtmR1frXrK for ; Mon, 31 Mar 2014 13:54:39 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2751A7021 for ; Mon, 31 Mar 2014 13:54:39 -0700 (PDT) Received: from [186.137.77.143] (helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WUjE2-0007Ho-FS; Mon, 31 Mar 2014 22:54:34 +0200 Message-ID: <5339D41B.4020509@si6networks.com> Date: Mon, 31 Mar 2014 17:46:19 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Qiong , opsec@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/A2sZ5u6gzXWufWXURwMfTgZiQis Subject: Re: [OPSEC] comments for firewall draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 20:54:42 -0000 Hi, Qiong, On 03/30/2014 11:30 PM, Qiong wrote: > > I recently read your draft draft-gont-opsec-ipv6-firewall-reqs-00 > . I > think it is quite useful for operators and it is in a good shape. Thanks > for your effort. > > Just a quick question: I think NAT is a quite common function in > firewall, is there some reason that it should not be included in IPv6 > firewall ? I'd say that, s far, it has not been included mostly because we have not yet worked out all requirements and details. That said, I'd bet you'd find a lot of opposition for such a requirement here at the IETF. Given that you've already raised the question, I'll essentially read the wg comments, and reflect the discussion in the next revision of the I-D. Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Mar 31 13:54:50 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEE81A7033 for ; Mon, 31 Mar 2014 13:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ipf8XdYtFwav for ; Mon, 31 Mar 2014 13:54:43 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id 54ECC1A7026 for ; Mon, 31 Mar 2014 13:54:43 -0700 (PDT) Received: from [186.137.77.143] (helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WUjE6-0007I0-E7; Mon, 31 Mar 2014 22:54:38 +0200 Message-ID: <5339D5BF.6050508@si6networks.com> Date: Mon, 31 Mar 2014 17:53:19 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "George, Wes" , Qiong , "opsec@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/nXRuJtbOew8MHxAAphU_jhSWubk Subject: Re: [OPSEC] comments for firewall draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 20:54:45 -0000 On 03/31/2014 08:34 AM, George, Wes wrote: > > From: Qiong > > > > Just a quick question: I think NAT is a quite common function in > firewall, is there some reason that it should not be included in IPv6 > firewall ? > > WG] Because NAT should not be used unless necessary. NAT is often > confused with security (i.e. security by obscurity), The thing is NAT, directly or indirectly bring: 1) Host/network masquerading 2) Diode-like firewall functionality (only allow communications initiated from the internal network). "2" is really a side affect, though. But the above are certainly interesting from a security pov. (Note: I'm not endorsing the use of NAT, nor suggesting that we should include anything about NATs in this I-D... Just trying to add another perspective). > but we’re really > trying to break that conflation in IPv6 since it is also not necessary > for address preservation and really shouldn’t be used for even 1:1 > address translation since it is possible to add multiple addresses for > hosts, so that they can have addresses for both internal and external > scope, rather than the existing private/public NAT that happens in many > networks today on IPv4. > > So if anything, the document probably needs words to that effect so that > it’s explicitly clear that this is a non requirement. I'll try to craft some text along these lines and post it to the mailing-list for review... Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Mon Mar 31 22:22:02 2014 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7661A075E for ; Mon, 31 Mar 2014 22:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBmQ5Q7lTJbM for ; Mon, 31 Mar 2014 22:21:57 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:8240:6:a::1]) by ietfa.amsl.com (Postfix) with ESMTP id E44701A0751 for ; Mon, 31 Mar 2014 22:21:56 -0700 (PDT) Received: from [186.137.77.143] (helo=[192.168.3.106]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WUr8v-000391-CJ; Tue, 01 Apr 2014 07:21:49 +0200 Message-ID: <533A16A5.8070304@si6networks.com> Date: Mon, 31 Mar 2014 22:30:13 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "George, Wes" , "Smith, Donald" , Qiong , "opsec@ietf.org" References: <68EFACB32CF4464298EA2779B058889D1244F90B@PDDCWMBXEX503.ctl.intranet> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/opsec/ZTUnBGSjPU5x3ST_KjQV9AcIqdg Subject: Re: [OPSEC] comments for firewall draft X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 05:21:59 -0000 Hi, Wes, On 03/31/2014 04:16 PM, George, Wes wrote: > >> Why does everyone believe NAT (NAPT really) is security by obscurity? >> For the port translation portion it makes it harder, 64k harder, to find >> the open ports (ok really less then 32k harder due to the birthday >> paradox but still). > WG] IMO “harder to attack because harder to find” is pretty much the > definition of security by obscurity. That’s not to say that security by > obscurity adds no value, but I don’t believe that it’s of such high value > that it can’t be replaced with other things. I think that each "mitigation" has it's place. Most of them are complementary. > My point is that justifying (or worse, REQUIRING) NAT in a firewall > because it gives you BCP38 or security by obscurity is solving for the > wrong thing and conflating the primary purpose of NAT (address > sharing/rewriting) with some of the arguably helpful side effects of using > it. Preventing spoofed traffic, and providing proper security is a good > goal. There are other ways to get there besides NAT. FWIW, I agree with the above. That said, we're specifying requirements as "required" and "optional", too. So one might least this feature as optional, without that meaning that supporting some sort of ipv6 nat functionality is really required. Against, I'm not yet arguing in favor or against some sort of IPv6 NAT, but rather trying to foster discussion of this topic. Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492