From bclaise@cisco.com Mon Oct 1 01:56:41 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71A921F8602 for ; Mon, 1 Oct 2012 01:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.651 X-Spam-Level: X-Spam-Status: No, score=-4.651 tagged_above=-999 required=5 tests=[AWL=-2.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KielpzVocwl1 for ; Mon, 1 Oct 2012 01:56:36 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCC921F84E6 for ; Mon, 1 Oct 2012 01:56:36 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q918uX7x020262 for ; Mon, 1 Oct 2012 10:56:34 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q918uWpm024734; Mon, 1 Oct 2012 10:56:32 +0200 (CEST) Message-ID: <50695AC0.6010200@cisco.com> Date: Mon, 01 Oct 2012 10:56:32 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Fred Baker (fred)" References: <5066CE05.4070501@lanparty.ee> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Fwd: [v6ops] Review requested, especially from operators X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 08:56:41 -0000 On 29/09/2012 13:24, Fred Baker (fred) wrote: > > Begin forwarded message: > >> From: Tarko Tikan >> Subject: Re: [v6ops] Review requested, especially from operators >> Date: September 29, 2012 12:31:33 PM GMT+02:00 >> To: "Fred Baker (fred)" >> >> hey, >> >> 2.3.2 mentions IPfix as management protocol but IPfix is push only and is not affected by ingress management ACL. >> >> 2.5 IPfix is incorrectly linked to RFC2740 (OSPFv6) Also it's actually IPFIX and not IPfix. There are also a couple of small corrections regarding IPFIX. I'll discuss them directly with KK, Eric, and Merike Regards, Benoit. >> >> Coming from someone who is working with IP/MPLS on daily basis, I'd add a little warning to 2.6.1. Dual-stack is indeed easy to turn on but if you run MPLS and expect your IPv6 traffic to be labelled same way your IPv4 is (BGP-free core, MPLS EXP based QOS, etc.), this is not going to happen and one should look into 6PE instead. >> >> Other than that, nice summary. >> >> -- >> tarko >> >> > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > From bclaise@cisco.com Mon Oct 1 02:10:59 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C9021F85E6 for ; Mon, 1 Oct 2012 02:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.632 X-Spam-Level: X-Spam-Status: No, score=-4.632 tagged_above=-999 required=5 tests=[AWL=-2.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv-blVh8MdEQ for ; Mon, 1 Oct 2012 02:10:58 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 6920521F85C7 for ; Mon, 1 Oct 2012 02:10:58 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q919Avkp022034 for ; Mon, 1 Oct 2012 11:10:57 +0200 (CEST) Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q919Aucx011001 for ; Mon, 1 Oct 2012 11:10:56 +0200 (CEST) Message-ID: <50695E20.1010409@cisco.com> Date: Mon, 01 Oct 2012 11:10:56 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "opsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [OPSEC] Feedback on draft-ietf-opsec-lla-only-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 09:10:59 -0000 Dear all, I discussed one topic off line with Eric, regarding http://tools.ietf.org/html/draft-ietf-opsec-lla-only-01 For the sake of openness, here it is again on the list. One on hand, the draft mentions: Lower configuration complexity: LLAs require no specific configuration, thereby lowering the complexity and size of router configurations. This also reduces the likelihood of configuration mistakes. On the other hand, the draft mentions: These link-local addresses SHOULD be hard-coded to prevent the change of EUI-64 addresses when changing of MAC address (such as after changing a network interface card). So the question is: who is going to configure this? If the NMS, there is not much of a gain in term of lower configuration complexity. We discussed the possibility of a global config on the router, for which the link-local addresses for that router would be generated from the UUID. Regards, Benoit From ipepelnjak@gmail.com Mon Oct 1 03:08:01 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4128E21F861F for ; Mon, 1 Oct 2012 03:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.443 X-Spam-Level: X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[AWL=1.156, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMQCTdUYWRwO for ; Mon, 1 Oct 2012 03:08:00 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2735721F861E for ; Mon, 1 Oct 2012 03:07:59 -0700 (PDT) Received: by wibhr7 with SMTP id hr7so1801169wib.13 for ; Mon, 01 Oct 2012 03:07:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=5JU7jssyTPwXRJns35i8GlzM349DikAgzkQ0bTfBxPw=; b=roD77j4BVA3dmtCrJ5S9Ilj8ZIP/Y2ZswzTSFCYCO4VA+OAY/uoVUOlDZQHk/Gxpv3 R48/p+wttzyF6jcPsLDxZn26sqFXBGauAlXJFXSssWn+9dIf2eJmSkjYuP+oNEu2egfB VKvzCYFfURESBQO0iHzJa9GEOiY2mdMTBesjOyjreN0/2nRvivGEn87kTXjuZm3QqqcM ujjaWsQ+xht4UE4dETgZEBBj/XVY7lKrYCH7c9N8JxJqbKSVxxqi0Xe5vtWFJ0iIRM03 QsHrO/wfZpLdMzAmUllyjVE/PNIFfSiqZM95z/GBPA/cf3mmQbo72EjDflZre64J2rvp 7t9Q== Received: by 10.216.133.91 with SMTP id p69mr6975877wei.111.1349086079215; Mon, 01 Oct 2012 03:07:59 -0700 (PDT) Received: from PIPINB2009 (BSN-142-19-163.dial-up.dsl.siol.net. [89.142.19.163]) by mx.google.com with ESMTPS id gm7sm5231563wib.10.2012.10.01.03.07.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Oct 2012 03:07:58 -0700 (PDT) From: "Ivan Pepelnjak" To: "'Benoit Claise'" , , "'Eric Vyncke \(evyncke\)'" References: <50695E20.1010409@cisco.com> In-Reply-To: <50695E20.1010409@cisco.com> Date: Mon, 1 Oct 2012 12:07:57 +0200 Message-ID: <00d201cd9fbc$a21c15b0$e6544110$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2ftLHTT5Z4SRggTGOVLyydmnR1rQABqqyw Content-Language: sl Subject: Re: [OPSEC] Feedback on draft-ietf-opsec-lla-only-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 10:08:01 -0000 As far as intra-AS infrastructure links are concerned, I'm perfectly = fine with the draft. HOWEVER, EBGP is a huge can of worms. While we can definitely make EBGP = work over link-local addresses, the interface name becomes part of EBGP = neighbor ID (at least in Cisco IOS), leading to a nightmare scenario if = you have to move the peering (or worse: IXP) link to another interface = in hurry. At least Junos has configuration identifier renaming = functionality ... Hallway discussions with a few IXP operators and IXP members during last = week's RIPE65 also indicated some lack of enthusiasm for this idea. I = know the sample was statistically irrelevant, but it was clear not = everyone wholeheartedly embraces EBGP-over-LLA concept. Ivan > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf = Of > Benoit Claise > Sent: Monday, October 01, 2012 11:11 AM > To: opsec@ietf.org > Subject: [OPSEC] Feedback on draft-ietf-opsec-lla-only-01 >=20 > Dear all, >=20 > I discussed one topic off line with Eric, regarding > http://tools.ietf.org/html/draft-ietf-opsec-lla-only-01 > For the sake of openness, here it is again on the list. >=20 > One on hand, the draft mentions: >=20 > Lower configuration complexity: LLAs require no specific > configuration, thereby lowering the complexity and size of router > configurations. This also reduces the likelihood of configuration > mistakes. >=20 > On the other hand, the draft mentions: >=20 > These link-local addresses SHOULD be hard-coded to prevent the = change > of EUI-64 addresses when changing of MAC address (such as after > changing a network interface card). >=20 > So the question is: who is going to configure this? If the NMS, there = is > not much of a gain in term of lower configuration complexity. >=20 > We discussed the possibility of a global config on the router, for = which > the link-local addresses for that router would be generated from the = UUID. >=20 > Regards, Benoit >=20 >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From gert@space.net Mon Oct 1 03:43:38 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5A221F84C5 for ; Mon, 1 Oct 2012 03:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wfq3M+zDaGre for ; Mon, 1 Oct 2012 03:43:38 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id C2ECF21F84C2 for ; Mon, 1 Oct 2012 03:43:36 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 10CD4F8CBD for ; Mon, 1 Oct 2012 12:43:35 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id D5267F8CA3 for ; Mon, 1 Oct 2012 12:43:33 +0200 (CEST) Received: (qmail 27066 invoked by uid 1007); 1 Oct 2012 12:43:33 +0200 Date: Mon, 1 Oct 2012 12:43:33 +0200 From: Gert Doering To: Ivan Pepelnjak Message-ID: <20121001104333.GP13776@Space.Net> References: <50695E20.1010409@cisco.com> <00d201cd9fbc$a21c15b0$e6544110$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00d201cd9fbc$a21c15b0$e6544110$@com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsec@ietf.org Subject: Re: [OPSEC] Feedback on draft-ietf-opsec-lla-only-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 10:43:38 -0000 Hi, On Mon, Oct 01, 2012 at 12:07:57PM +0200, Ivan Pepelnjak wrote: > Hallway discussions with a few IXP operators and IXP members during last week's RIPE65 also indicated some lack of enthusiasm for this idea. I know the sample was statistically irrelevant, but it was clear not everyone wholeheartedly embraces EBGP-over-LLA concept. Call me old-fashioned and IPv4-minded, but I *like* having well-defined transit networks at IXPs. With addresses I can ping from my desktop to see whether something is broken, for example, or verify with a quick traceroute to see which of multiple paths between us and a remote network a packet is taking (consider one router being connected to two exchange points - maybe not a typical case, but we have that, and we see some peers on both IXPs). I consider LLAs as useful for protocols with automatic neighbour discovery (OSPFv3 and such), but for BGP, and network monitoring it's more hindrance than benefit. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From list-opsec@dragon.net Mon Oct 1 05:20:28 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C99021F86DB for ; Mon, 1 Oct 2012 05:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buc4JtvyadKe for ; Mon, 1 Oct 2012 05:20:26 -0700 (PDT) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5711321F8705 for ; Mon, 1 Oct 2012 05:20:26 -0700 (PDT) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by mail.dragon.net (Postfix) with ESMTP id D6E1A374028B for ; Mon, 1 Oct 2012 05:20:24 -0700 (PDT) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id CF9BF1192239; Mon, 1 Oct 2012 16:20:23 +0400 (MSK) Received: from fafnir.remote.dragon.net (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id CF3571192238 for ; Mon, 1 Oct 2012 16:20:23 +0400 (MSK) To: opsec@ietf.org From: Paul Ebersman In-reply-to: <00d201cd9fbc$a21c15b0$e6544110$@com> References: <50695E20.1010409@cisco.com> <00d201cd9fbc$a21c15b0$e6544110$@com> Comments: In-reply-to "Ivan Pepelnjak" message dated "Mon, 01 Oct 2012 12:07:57 +0200." X-Mailer: MH-E 7.4.2; nmh 1.3; XEmacs 21.4 (patch 22) Date: Mon, 01 Oct 2012 16:20:23 +0400 Message-Id: <20121001122023.CF9BF1192239@fafnir.remote.dragon.net> Subject: Re: [OPSEC] Feedback on draft-ietf-opsec-lla-only-01 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 12:20:28 -0000 ipepelnjak> Hallway discussions with a few IXP operators and IXP members ipepelnjak> during last week's RIPE65 also indicated some lack of ipepelnjak> enthusiasm for this idea. I know the sample was ipepelnjak> statistically irrelevant, but it was clear not everyone ipepelnjak> wholeheartedly embraces EBGP-over-LLA concept. Seem to recall less than enthusiastic response from operators at IETF and NANOG too. Breaks tools and debugging procedures for too many folks, with massive retraining of NOCs for too little improvement in security. From jerduran@cisco.com Mon Oct 1 05:46:14 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7146F21F8812 for ; Mon, 1 Oct 2012 05:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.178 X-Spam-Level: X-Spam-Status: No, score=-8.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMP6JbTcU+Zt for ; Mon, 1 Oct 2012 05:46:13 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0C0E521F8867 for ; Mon, 1 Oct 2012 05:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14742; q=dns/txt; s=iport; t=1349095573; x=1350305173; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ElqQV4qsM6wkqCGnzES2EPyhCCwJe0awCeVM8Z9XZos=; b=cLlYRWvgLgcjRHYceeVw4o/uEHaHmahKOmvMinjCgcYeN8HThVUYGh54 KGtHXE6sgVKmlm77TxM1Mv3YeSRgQL/EIHrF9J0bbxvGauRaUWZHz5f5U Lc8hjHkXE1A2t9wSLik+Xj5hIIB5IyY2keFy2Z5X9sRqqsDZObP5zyAkl o=; X-Files: logo.gif, green.gif : 837, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8FALKPaVCtJV2Z/2dsb2JhbABFgkuqHIhrAYhmgQiCIQEBBAEBAQIHBgEbGxsKCxACAQgdAQEBAh0HAgUQDwELFBECBA4EAQgGFIdjC5pYn3KLOYVRYAOQDgGGb40tgWmCZ4FjNA X-IronPort-AV: E=Sophos;i="4.80,515,1344211200"; d="gif'147?scan'147,208,217,147";a="124051669" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 01 Oct 2012 12:46:12 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q91CkC98009510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Oct 2012 12:46:12 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.4]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Mon, 1 Oct 2012 07:46:12 -0500 From: "Jerome Durand (jerduran)" To: Gert Doering Thread-Topic: [OPSEC] Comments on draft-jdurand-bgp-security-02 Thread-Index: AQHNnKu3WrxGACmI90KZhJSLw3Z/15eeeWkAgAZGiAA= Date: Mon, 1 Oct 2012 12:46:11 +0000 Message-ID: <0145702467942740A26A9633AA8B60FA1F8BE1FE@xmb-rcd-x01.cisco.com> References: <20120927125610.GC13776@Space.Net> In-Reply-To: <20120927125610.GC13776@Space.Net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [64.103.29.199] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19226.000 x-tm-as-result: No--46.286700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/related; boundary="_005_0145702467942740A26A9633AA8B60FA1F8BE1FExmbrcdx01ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] Comments on draft-jdurand-bgp-security-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 12:46:14 -0000 --_005_0145702467942740A26A9633AA8B60FA1F8BE1FExmbrcdx01ciscoc_ Content-Type: multipart/alternative; boundary="_000_0145702467942740A26A9633AA8B60FA1F8BE1FExmbrcdx01ciscoc_" --_000_0145702467942740A26A9633AA8B60FA1F8BE1FExmbrcdx01ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Also, are you aware that some networks inject the IXP LAN into their IGP for the purposes of TE? (I.e leaving the IXP LAN next hop present in their iBGP and then doing MPLS TE on this LAN as opposed to next-hop-self on the border where all peering networks are collapsed into a single loopback) Yeah, I did. At some point. Hi all, I did too for managing my 2 exits to a single IXP. This had rgeat advantage= s: simple and best for convergence with Cisco BGP PIC. However I had big problems few times when PE redistributed the LAN prefix w= hile there was no connectivity due to broken switch fabric on Brocade MLX o= f the IXP. (Note I was managing also the IXP so no excuse! :-) =85 So I dec= ided to change this for next-hop-self :-) SHOULD works for me then :-) Cheers, Jerome Maybe we need to add a bit more language to the point of "if you need to deviate from these recommendations, understand why you are doing this, and then feel free to do so" (=3D "SHOULD" normative language). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec [cid:64A2AD8F-2887-4ECC-AD2A-E695929D6837@cisco.com] J=E9r=F4me Durand Consulting Systems Engineer Routing & Switching jerduran@cisco.com Mobile :+33 6 35 11 60 50 http://reseauxblog.cisco.fr http://ipv6blog.cisco.fr Cisco France 11, rue Camille Desmoulins 92782 Issy les Moulineaux Cedex 9 France www.cisco.fr [cid:7248AA9E-F798-45B3-9917-F1BBD75CD002@cisco.com] Think before you print. This e-mail may contain confidential and privileged material for the sole u= se of the intended recipient. Any review, use, distribution or disclosure b= y others is strictly prohibited. If you are not the intended recipient (or = authorized to receive for the recipient), please contact the sender by repl= y e-mail and delete all copies of this message. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_0145702467942740A26A9633AA8B60FA1F8BE1FExmbrcdx01ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <40DD2B025289B446A6E00401ABFD51F5@cisco.com> Content-Transfer-Encoding: quoted-printable

Also, are you aware that some networks inject the= IXP
LAN into their IGP for the purposes of TE? (I.e l= eaving
the IXP LAN next hop present in their iBGP and th= en
doing MPLS TE on this LAN as opposed to next-hop-= self
on the border where all peering networks are coll= apsed
into a single loopback)

Yeah, I did.  At some point.

Hi all,

I did too for managing my 2 exits to a single IXP. This had rgeat adva= ntages: simple and best for convergence with Cisco BGP PIC.
However I had big problems few times when PE redistributed the LAN pre= fix while there was no connectivity due to broken switch fabric on Brocade = MLX of the IXP. (Note I was managing also the IXP so no excuse! :-) =85 So = I decided to change this for next-hop-self :-)
SHOULD works for me then :-)


Cheers,

Jerome








Maybe we need to add a bit more language to the point of "if you
need to deviate from these recommendations, understand why you are
doing this, and then feel free to do so" (=3D "SHOULD" norma= tive
language).

Gert Doering
       -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG           &nb= sp;            = Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14         &= nbsp;Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen          &nbs= p;        HRB: 136055 (AG Muenchen)=
Tel: +49 (89) 32356-444         = ;   USt-IdNr.: DE813185279
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec


J=E9r=F4me Durand
Consulting Systems Engineer
Routing & Switching

jerduran@cisco.com
Mobile :+33 6 35 11 60 50

http://reseauxblog.cisco.fr<= /a>

http://ipv6blog.cisco.fr

Cisco France
11, rue Camille Desmoulins
92782 Issy les Moulineaux
Cedex 9
France
www.c= isco.fr

  


 Think before you print.
This e-mail may contain confidential and privileged material for the sole u= se of the intended recipient. Any review, use, distribution or disclosure b= y others is strictly prohibited. If you are not the intended recipient (or = authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this me= ssage.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html<= /td>

--_000_0145702467942740A26A9633AA8B60FA1F8BE1FExmbrcdx01ciscoc_-- --_005_0145702467942740A26A9633AA8B60FA1F8BE1FExmbrcdx01ciscoc_ Content-Type: image/gif; name="logo.gif" Content-Description: logo.gif Content-Disposition: inline; filename="logo.gif"; size=837; creation-date="Mon, 01 Oct 2012 12:46:11 GMT"; modification-date="Mon, 01 Oct 2012 12:46:11 GMT" Content-ID: <64A2AD8F-2887-4ECC-AD2A-E695929D6837@cisco.com> Content-Transfer-Encoding: base64 R0lGODlhbgBJAMQAAP///3OXqtapqq1MTcmRki9mgZkAALpqbMl/f6g5O/Xq6+vX2OTIyaMqK/nz 9OW/v5sVFsbV3Nfh5p0PD5kFBf78/P38/Pz6+v/+/rZdXpcKDKAhIvv396QvMO/g4Ny4uSH5BAAA AAAALAAAAABuAEkAQAX/ICCOZGmeaKqubOu+cCzPdG3feK6nkln8pp5LSPoVgrucsbQsAp1HKPM5 alapImtyy+16SwKDmJBCiBEWgMUsPgg8JMHEQCGTMACP2HDgiBQZYglfOQ+GDy2HhiqKKI2EkJGS k5SVlpeYmZpfWkpYmypEV1GjU6QjolmfnZ0AqZWvrj6fski2UiWxsZkcHxkNYg0IABUibAjFIgsH wAYNBwokvb8QEMIOJAwICQYQCQgLoCgLHWIdHwoKCwzExmdpGBwcxRgDYhkXAOTm6OoMfg4CiRGg wAOBOXzEKVzIsKHDhxAjSpxIsaKNCAEibMGo0WKLVjdAVgxQIICpEiRN/7JIeZIEy4WsVsk8BSAm TZstLb0csVMVzZ4AgALtJLQkRY4bM3pcupDAHgMduA1Q484AGmJO7x04kCCaCAIaxFCISmGAVwZP u+1pEK5hVgPYUBxLQ4yBvacfvlIwMCFuCbRi2I34sHfDQ0BpDUyFNxfABTZPGwgGACjsU7MiLLx9 ukEA08+gQ4seTbq06dOoU6tezbq169evd92QHRooDtujRdbQDZr3DN8RkeIaIXxFcZ8ljkPEOVwF 81ILlT9HTkL6zJwilE+aXvN68+43vUO3xL28eOrj0VdSbp0me6XV4acH8L6jRNw28IumXYM/7P8k PJLIISkIWIKBD3GwmcIYiwGAQWP6cJMWHCIoCEFamInwQTNPdYCIQwqUM8YCC3zgWTKNOXAAg14p kA9lIkJAAIkmYsPBim0YcsBeVjn0llcnQAjYHh14phdfQGazx2QAEGaAYQ2FMVAZ75BggTZ7HFCM HHQYWcICeyAjgormPASZYgN00CAAjV0gwAEEEACZlsbwCMEAaWb4wFMJJMDjBkwypAABErbRzoNn FFPBghnkRcKgCVimwQF+VSDAXXw1CuCmnHbq6aeghirqqDiEAAA7 --_005_0145702467942740A26A9633AA8B60FA1F8BE1FExmbrcdx01ciscoc_ Content-Type: image/gif; name="green.gif" Content-Description: green.gif Content-Disposition: inline; filename="green.gif"; size=87; creation-date="Mon, 01 Oct 2012 12:46:11 GMT"; modification-date="Mon, 01 Oct 2012 12:46:11 GMT" Content-ID: <7248AA9E-F798-45B3-9917-F1BBD75CD002@cisco.com> Content-Transfer-Encoding: base64 R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --_005_0145702467942740A26A9633AA8B60FA1F8BE1FExmbrcdx01ciscoc_-- From gvandeve@cisco.com Wed Oct 3 01:48:14 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EFC21F86B3 for ; Wed, 3 Oct 2012 01:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.327 X-Spam-Level: X-Spam-Status: No, score=-12.327 tagged_above=-999 required=5 tests=[AWL=2.272, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjZNmFRL1csl for ; Wed, 3 Oct 2012 01:48:13 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 67B0821F86AB for ; Wed, 3 Oct 2012 01:48:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7624; q=dns/txt; s=iport; t=1349254087; x=1350463687; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TGTBT99zgvDPgEkyJsTET8SHtRxv5O6MLv2b4ZQnKoA=; b=kXWwrGbT7Y9y1tFFnMzwSAlAnekETKoICy0/VB2dxKQcJWxdXivk/5QZ b1cdbSj1WnDGjwWbhGctM8JddSQiLk18oAGAECcYa45i663ukwz0nxAl0 C/EvDGBpJ628xspitS4Ci+rRb+6D5rqrm1PbGT/oLlSeld3pkGu3A7yn6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEX7a1CtJXG//2dsb2JhbABEhg23Y4ECgQiCIAEBAQQBAQEPARAROgcQBAIBCBEDAQEBAwIGHQMCAgIlCxQBBgEBBQMCBBMIARmFb4F0C5ghjRuSZoEhigIkhQQyYAOWfooOgx+BaYJngVoEBTQ X-IronPort-AV: E=Sophos;i="4.80,527,1344211200"; d="scan'208";a="127832006" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 03 Oct 2012 08:48:06 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q938m6c5018486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Oct 2012 08:48:06 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.113]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Wed, 3 Oct 2012 03:48:06 -0500 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: IETF 85 - Meeting Information Thread-Index: AQHNoPuQQ91G3E6AkECcVOoZA2zB6ZenRYAw Date: Wed, 3 Oct 2012 08:48:06 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240816AB3A@xmb-aln-x12.cisco.com> References: <20121003000945.15418.42355.idtracker@ietfa.amsl.com> In-Reply-To: <20121003000945.15418.42355.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.86.193] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19234.001 x-tm-as-result: No--48.034600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [OPSEC] FW: IETF 85 - Meeting Information X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 08:48:14 -0000 U29tZSBpbnRlcmVzdGluZyBtZWV0aW5nIGluZm9ybWF0aW9uIGZvciBJRVRGODUNCg0KRy8NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHdnY2hhaXJzLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzp3Z2NoYWlycy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSUVURiBT ZWNyZXRhcmlhdA0KU2VudDogMDMgT2N0b2JlciAyMDEyIDAyOjEwDQpUbzogSUVURiBBbm5vdW5j ZW1lbnQgTGlzdA0KQ2M6IHdnY2hhaXJzQGlldGYub3JnOyBpcnNnQGlydGYub3JnDQpTdWJqZWN0 OiBJRVRGIDg1IC0gTWVldGluZyBJbmZvcm1hdGlvbg0KDQo4NXRoIElFVEYgTWVldGluZw0KQXRs YW50YSwgR0EsIFVTQQ0KTm92ZW1iZXIgNC05LCAyMDEyDQpIb3N0OiBOb3J0aCBBbWVyaWNhbiBD YWJsZSBJbmR1c3RyeQ0KDQpNZWV0aW5nIHZlbnVlOiAgSGlsdG9uIEF0bGFudGEgaHR0cDovL3d3 dzMuaGlsdG9uLmNvbS9lbi9ob3RlbHMvZ2VvcmdpYS9oaWx0b24tYXRsYW50YS1BVExBSEhIL2lu ZGV4Lmh0bWwNCg0KUmVnaXN0ZXIgb25saW5lIGF0OiBodHRwOi8vd3d3LmlldGYub3JnL21lZXRp bmdzLzg1Lw0KDQoxLiAgUmVnaXN0cmF0aW9uDQoyLiAgVmlzYXMgJiBMZXR0ZXJzIG9mIEludml0 YXRpb24NCjMuICBTb2NpYWwgRXZlbnQNCjQuICBVUyBQcmVzaWRlbnRpYWwgRWxlY3Rpb24NCjUu ICBBY2NvbW1vZGF0aW9ucw0KNi4gIENvbXBhbmlvbiBQcm9ncmFtDQo3LiAgTm9ydGggQW1lcmlj YW4gQ2FibGUgSW5kdXN0cnkNCg0KMS4gUmVnaXN0cmF0aW9uDQogICAgQS4gRWFybHktQmlyZCBS ZWdpc3RyYXRpb24gLSBVU0QgNjUwLjAwIFBheSBieSBGcmlkYXksIDI2IE9jdG9iZXIgMjAxMiBV VEMgMjQ6MDANCiAgICBCLiBBZnRlciBFYXJseS1CaXJkIGN1dG9mZiAtIFVTRCA4MDAuMDANCiAg ICBDLiBGdWxsLXRpbWUgU3R1ZGVudCBSZWdpc3RyYXRpb25zIC0gVVNEIDE1MC4wMCAod2l0aCBw cm9wZXIgSUQpDQogICAgRC4gT25lIERheSBQYXNzIFJlZ2lzdHJhdGlvbiAtIFVTRCAzNTAuMDAN CiAgICBFLiBSZWdpc3RyYXRpb24gQ2FuY2VsbGF0aW9uICAgDQogICAgICAgICAgICAgICAgQ3V0 LW9mZiBmb3IgcmVnaXN0cmF0aW9uIGNhbmNlbGxhdGlvbiBpcyBNb25kYXksDQogICAgICAgICAg ICAgICAgMjkgT2N0b2JlciAyMDEyIGF0IFVUQyAyNDowMC4NCiAgICAgICAgICAgICAgICBDYW5j ZWxsYXRpb25zIGFyZSBzdWJqZWN0IHRvIGEgMTAlICh0ZW4gcGVyY2VudCkNCiAgICAgICAgICAg ICAgICBjYW5jZWxsYXRpb24gZmVlIGlmIHJlcXVlc3RlZCBieSB0aGF0IGRhdGUgYW5kIHRpbWUu DQogICAgRi4gT25saW5lIFJlZ2lzdHJhdGlvbiBhbmQgUGF5bWVudCBlbmRzIEZyaWRheSwgMiBO b3ZlbWJlciAyMDEyLCAxNzAwIGxvY2FsIEF0bGFudGEgdGltZS4NCiAgICBHLiBPbi1zaXRlIFJl Z2lzdHJhdGlvbiBzdGFydGluZyBTdW5kYXksIDQgTm92ZW1iZXIgMjAxMiBhdCAxMTAwIGxvY2Fs IEF0bGFudGEgdGltZS4NCg0KMi4gVmlzYXMgJiBMZXR0ZXJzIG9mIEludml0YXRpb246DQogICAg SW5mb3JtYXRpb24gb24gVmlzaXRpbmcgdGhlIFVuaXRlZCBTdGF0ZXMsIHBsZWFzZSB2aXNpdDoN Cmh0dHA6Ly90cmF2ZWwuc3RhdGUuZ292L3Zpc2EvDQoNCiAgICBBZnRlciB5b3UgY29tcGxldGUg dGhlIHJlZ2lzdHJhdGlvbiBwcm9jZXNzLCB5b3UgY2FuIHJlcXVlc3QgYW4gZWxlY3Ryb25pYyBJ RVRGIGxldHRlciBvZiBpbnZpdGF0aW9uIGFzIHdlbGwgYXMgYW4gZWxlY3Ryb25pYyBIb3N0IGxl dHRlciBvZiBpbnZpdGF0aW9uLiBUaGUgcmVnaXN0cmF0aW9uIHN5c3RlbSBhbHNvIGFsbG93cyBm b3IgeW91IHRvIHJlcXVlc3QgYSBoYXJkIGNvcHkgSUVURiBsZXR0ZXIgb2YgaW52aXRhdGlvbiBh bmQgYSBoYXJkIGNvcHkgSG9zdCBsZXR0ZXIgb2YgaW52aXRhdGlvbi4gWW91IG1heSBhbHNvIHJl cXVlc3Qgb25lIGF0IGEgbGF0ZXIgdGltZSBieSBmb2xsb3dpbmcgdGhlIGxpbmsgcHJvdmlkZWQg aW4gdGhlIGNvbmZpcm1hdGlvbiBlbWFpbC4NCg0KICAgIFBsZWFzZSBub3RlIHRoYXQgdGhlIElF VEYgTGV0dGVyIG9mIEludml0YXRpb24gbWF5IG5vdCBiZSBzdWZmaWNpZW50IGZvciBvYnRhaW5p bmcgYSB2aXNhIHRvIGVudGVyIHRoZSBVbml0ZWQgU3RhdGVzLg0KDQozLiBTb2NpYWwgRXZlbnQN CklFVEYgODUgLSBTb2NpYWwgRXZlbnQNCldoZXJlOiBHZW9yZ2lhIERvbWUNCkRhdGU6IFR1ZXNk YXksIE5vdmVtYmVyIDYsIDIwMTINClRpbWU6IDE5OjAwIC0gMjM6MDAgaG91cnMNCkNvc3Q6ICQz NSBVU0QgcGVyIHBlcnNvbi4NCkF2YWlsYWJpbGl0eTogT3BlbiB0byBhbGwhIQ0KSG9zdDogTm9y dGggQW1lcmljYW4gQ2FibGUgSW5kdXN0cnkNCg0KLSBUaGUgSUVURiA4NSBzb2NpYWwgZXZlbnQg d2lsbCB0YWtlIHBsYWNlIG9uIGZsb29yIG9mIHRoZSBHZW9yZ2lhIERvbWUsIGluY2x1ZGluZyB0 aGUgZW50aXJlIGZpZWxkISENCi0gR3Vlc3RzIHdpbGwgYXJyaXZlIHRocm91Z2ggdGhlIGlubmVy IGNvcnJpZG9ycyBvZiB0aGUgR2VvcmdpYSBEb21lIGFuZCBlbnRlcmluZyB0aGUgZmllbGQgdGhy b3VnaCB0aGUgc2FtZSBicmVlemV3YXkgYXMgdGhlIEF0bGFudGEgRmFsY29ucyBvbiBnYW1lIGRh eSEhDQotIFNwZWNpYWwgcGVyZm9ybWFuY2UgYnkgdGhlIEF0bGFudGEgRHJ1bWxpbmUsIHNob3dj YXNpbmcgQXRsYW50YSdzIGZpbmVzdCB5b3VuZyBwZXJjdXNzaW9uaXN0cw0KLSBVLlMuIGVsZWN0 aW9uIGNvdmVyYWdlIHdpbGwgYmUgZGlzcGxheWVkIG9uIHRoZSAiSnVtYm90cm9uIg0KLSBPbi1m aWVsZCBhY3Rpdml0aWVzIHRvIGluY2x1ZGU6IFBvcC1hLVNob3QsIEVsZWN0cm9uaWMgRGFydHMs IFBvb2wgVGFibGVzLCBBaXIgSG9ja2V5LCBUYWJsZSBUZW5uaXMsIEZpZWxkIEdvYWwgS2lja2lu ZyBhbmQgbW9yZSEhDQotIERlbGljaW91cyBsb2NhbCBjdWlzaW5lIHRvIHN1aXQgYSB2YXJpZXR5 IG9mIGRpZXRhcnkgcmVzdHJpY3Rpb25zICoqbWVudSB3aWxsIGJlIHBvc3RlZCB0byB0aGUgaG9z dCB3ZWJzaXRlIHNvb24hKioNCg0KRm9yIG1vcmUgaW5mb3JtYXRpb24gdmlzaXQ6IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvbWVldGluZy84NS9zb2NpYWwuaHRtbA0KDQpOT1RFOiBZb3UgbXVzdCBiZSBy ZWdpc3RlcmVkIGZvciBJRVRGIDg1IHRvIHB1cmNoYXNlIGEgU29jaWFsIFRpY2tldC4gSWYgeW91 IGhhdmUgYWxyZWFkeSByZWdpc3RlcmVkIGZvciB0aGUgSUVURiwgcGxlYXNlIHVzZSB0aGlzIGxp bmsgdG8gcHVyY2hhc2UgYSBzb2NpYWwgdGlja2V0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmVn aXN0cmF0aW9uL2lldGY4NS9ldmVudHRpY2tldC5weSANCg0KNC4gIFVTIFByZXNpZGVudGlhbCBF bGVjdGlvbg0KDQpXaXRoIElFVEYgODUgdGFraW5nIHBsYWNlIGluIHRoZSBVbml0ZWQgU3RhdGVz LCBpdCBzZWVtcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IHRoZSBVbml0ZWQgU3RhdGVzIFByZXNp ZGVudGlhbCBFbGVjdGlvbiBpcyB0YWtpbmcgcGxhY2Ugb24gVHVlc2RheSwgTm92ZW1iZXIgNiwg d2hpY2ggaXMgaW4gdGhlIG1pZGRsZSBvZiB0aGUgbWVldGluZy4gTm9uLVVTIHJlc2lkZW50cyBt YXkgd2FudCB0byBrZWVwIGluIG1pbmQgdGhhdCBsb2NhbCBtZWRpYSBjb3ZlcmFnZSBkdXJpbmcg dGhpcyB0aW1lIHdpbGwgcHJvYmFibHkgZm9jdXMgb24gdGhlIGVsZWN0aW9uLiBVUyByZXNpZGVu dHMgd2hvIGludGVuZCB0byB2b3RlIGluIHRoZSBlbGVjdGlvbiBzaG91bGQgcGxhbiBhY2NvcmRp bmdseS4NCg0KQWRkaXRpb25hbCBJbmZvcm1hdGlvbjogQ2FuIEkgVm90ZSwgd2hpY2ggcHJvdmlk ZXMgbGlua3MgdG8gZWFjaCBzdGF0ZSdzIHZvdGluZyBydWxlcyAtLSBpbmNsdWRpbmcgZWFybHkg YW5kIGFic2VudGVlIHZvdGluZyBydWxlcy4NCg0KNS4gIEFjY29tbW9kYXRpb25zDQogICAgVGhl IElFVEYgaXMgaG9sZGluZyBhIGJsb2NrIG9mIGd1ZXN0IHJvb21zIGF0IHRoZSBIaWx0b24gQXRs YW50YSwgdGhlIG1lZXRpbmcgdmVudWUuDQoNCiAgICBSb29tIFJhdGVzDQogICAgUnVuIG9mIEhv dXNlOiBTaW5nbGUgJDE4OTsgRG91YmxlICQxOTkNCiAgICBFeGVjdXRpdmUgTGV2ZWw6IFNpbmds ZTogJDIyOTsgRG91YmxlICQyMzkNCiAgICBSb29tIFJhdGVzIGluY2x1ZGUgaW4gcm9vbSBoaWdo LXNwZWVkIEludGVybmV0IGFjY2Vzcy4gQ2l0eSBhbmQgU3RhdGUgVGF4ZXMgb2YgMTUlIChhcHBs aWNhYmxlIHRheGVzIGFyZSBzdWJqZWN0IHRvIGNoYW5nZSkgYXJlIGV4Y2x1ZGVkIGZyb20gdGhl IGd1ZXN0IHJvb20gcmF0ZS4gUm9vbSByYXRlcyBETyBOT1QgaW5jbHVkZSBkYWlseSBicmVha2Zh c3QuDQoNCiAgICBSZXNlcnZhdGlvbnMgQ3V0IG9mZiBEYXRlOiAxNSBPY3RvYmVyIDIwMTIgDQoN CkZvciBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIG9uIHJhdGVzIGFuZCBwb2xpY2llcywgcGxlYXNl IHZpc2l0Omh0dHA6Ly93d3cuaWV0Zi5vcmcvbWVldGluZy84NS9ob3RlbC5odG1sDQoNCjYuICBD b21wYW5pb24gUHJvZ3JhbQ0KICAgSWYgeW91IGFyZSB0cmF2ZWxpbmcgd2l0aCBhIGZyaWVuZCBv ciBmYW1pbHkgbWVtYmVyIG92ZXIgMTggeWVhcnMgb2YgYWdlIHlvdSBjYW4gcmVnaXN0ZXIgdGhl bSBmb3IgdGhlIElFVEYgQ29tcGFuaW9uIFByb2dyYW0gZm9yIG9ubHkgVVNEIDI1LjAwDQoNCiAg IEJlbmVmaXRzIGluY2x1ZGU6DQogICAtIEEgc3BlY2lhbCB3ZWxjb21lIHJlY2VwdGlvbiBmb3Ig Y29tcGFuaW9ucyBmcm9tIDE2MzAtMTczMCBvbiBTdW5kYXksIDQgTm92ZW1iZXINCiAgIC0gQWJp bGl0eSB0byBhdHRlbmQgdGhlIG9mZmljaWFsIFdlbGNvbWUgUmVjZXB0aW9uIGZyb20gMTcwMC0x OTAwIG9uIFN1bmRheSwgNCBOb3ZlbWJlcg0KICAgLSBBIGRpc3RpbmN0aXZlIG1lZXRpbmcgYmFk Z2UgdGhhdCBncmFudHMgYWNjZXNzIHRvIHRoZSB2ZW51ZSAobm90IHRvIGJlIHVzZWQgdG8gYXR0 ZW5kIHdvcmtpbmcgc2Vzc2lvbnMpDQogICAtIFBhcnRpY2lwYXRpb24gaW4gYSBzZXBhcmF0ZSBj b21wYW5pb24gZW1haWwgbGlzdCBpZiB5b3UgY2hvb3NlIHRvIGhlbHAgY29tbXVuaWNhdGUgYW5k IG1ha2UgcGxhbnMgd2l0aCBvdGhlciBJRVRGIENvbXBhbmlvbnMuDQoNCiAgIFlvdSBjYW4gcmVn aXN0ZXIgeW91ciBjb21wYW5pb24gYXQgYW55IHRpbWUgdmlhIHRoZSBJRVRGIHdlYnNpdGUgb3Ig b25zaXRlIGF0IHRoZSBtZWV0aW5nLg0KDQogICBUbyBqb2luIHRoZSA4NSBjb21wYW5pb25zIG1h aWxpbmcgbGlzdCBzZWU6DQogICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv Lzg1Y29tcGFuaW9ucw0KDQo3LiAgTm9ydGggQW1lcmljYW4gQ2FibGUgSW5kdXN0cnkNClBsYXRp bnVtDQotIENvbWNhc3QNCi0gVGltZSBXYXJuZXIgQ2FibGUNCkdvbGQNCi0gQ2FibGVMYWJzDQot IE5hdGlvbmFsIENhYmxlICYgVGVsZWNvbW11bmljYXRpb25zIEFzc29jaWF0aW9ucyBTaWx2ZXIN Ci0gQnJpZ2h0aG91c2UNCi0gQ2FibGV2aXNpb24NCi0gQ2hhcnRlcg0KLSBDb3gNCi0gUm9nZXJz DQoNCk9ubHkgMzIgZGF5cyB1bnRpbCB0aGUgQXRsYW50YSBJRVRGIQ0K From tim@haitabu.net Wed Oct 3 08:27:21 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4810A21F841B for ; Wed, 3 Oct 2012 08:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cd1Z8bHh9MGU for ; Wed, 3 Oct 2012 08:27:20 -0700 (PDT) Received: from samstag.members.selfnet.de (samstag.members.selfnet.de [IPv6:2001:7c0:e701:800::199]) by ietfa.amsl.com (Postfix) with ESMTP id 38C2F21F849D for ; Wed, 3 Oct 2012 08:27:20 -0700 (PDT) Received: from [192.168.178.19] (HSI-KBW-046-005-022-247.hsi8.kabel-badenwuerttemberg.de [46.5.22.247]) by samstag.members.selfnet.de (Postfix) with ESMTPSA id 764A721C034 for ; Wed, 3 Oct 2012 17:27:17 +0200 (CEST) Message-ID: <506C5954.9050807@haitabu.net> Date: Wed, 03 Oct 2012 17:27:16 +0200 From: Tim Kleefass User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "opsec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [OPSEC] Comments on draft-jdurand-bgp-security-02 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 15:27:21 -0000 Hi there, Some comments and thoughts. * next-hop filtering possible (If had sent this only to the authors, but maybe the list is also interested.) Regarding Section 9. Next-Hop Filtering With IOS XR one can match the next-hop in a route-policy (but I have never used it, so no real-life experience): Example on Cisco ASR 9000, IOS XR 4.1.1: route-policy test if not next-hop in (192.0.2.1) then drop endif ... end-policy One can also state a prefix-list instead a single IPv4/IPv6 address. So this could by an alternative to setting the next-hop by hard. This could be interesting if you have on an IXP two peering sessions to the same ISP and want to allow this ISP to play with the next-hop. Or you could apply an prefix-list to the peering with the route-server of an IXP to make sure that through this peerings only valid next-hops are announced. But probably one trusts this route-servers and such a setup would be overkill... * About route flap dampening """ 6. BGP route flap dampening BGP route flap dampening mechanism makes it possible to give penalties to routes each time they change in the BGP routing table. Initially this mechanism was created to protect the entire internet from multiple events impacting a single network. RIPE community now recommends not using BGP route flap dampening [20]. Author of this document proposes to follow the proposal of the RIPE community. """ On that topic there are some "updates" at the RIPE-64: Randy Bush, Route Flap Damping Considered Usable @ RIPE-64 https://ripe64.ripe.net/presentations/136-120418.ripe-rfd.pdf https://ripe64.ripe.net/archives/video/80 [routing-wg] Route flap damping considered usable http://www.ripe.net/ripe/mail/archives/routing-wg/2012-July/002163.html So maybe the recommendation of the RIPE community will change in the future... * stable eBGP announcement Talking about route flap dampening, it could be a good idea to prevent routes from flapping in the first place and I haven't seen that in the draft (the focus is on security, but as route flap dampening is named...). If you are the origin of a prefix you want to announce that prefix in a very stable way. For example, if you are stub, configure on two router a null-route for that prefix and inject it into BGP. There are also situations where an ISP can help stub customers with an stable eBGP announcement. We have several single-homed customers (customers that are only connected to us and no other ISP). These customers have their own IPv4 (legacy) space. In the RIPE region the requirement for IPv6 PI space to be at least dual-homed was canceled. So there could also be single-homed customers with an own IPv6 space. Such customers are connected to us with static routes (then we put their prefix in BGP) or via BGP (and private AS numbers; which we strip before announcing to others). For them we put a "backup null-route" on two of our core routers, so that if the connection to the customer fails we still have a route to the prefix and the prefix is injected into BGP and announced into the Internet. Example on Cisco ASR 9000, IOS XR 4.1.1: router static address-family ipv4 unicast 192.0.2.0/24 Null0 240 ! ^^^ administrative distance of 240 ! higher than OSPF and BGP ! ! router bgp 553 address-family ipv4 unicast ! BelWue network 192.0.2.0/24 route-policy ebgp-null-route ! ^^ the route-policy sets (only) a community ! ! * private AS numbers In Section 8. AS-path filtering """ o Do not advertise private AS numbers. Exception: Customers using BGP without having their own AS number must use private AS numbers to advertise their prefixes to their upstream. The private AS number is usually provided by the upstream. """ An then strip the private AS number before announcing that prefix to others ISPs. Cheers, Tim From kkumar@google.com Thu Oct 4 13:32:35 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F4E21F8737 for ; Thu, 4 Oct 2012 13:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHwNViZw98Nw for ; Thu, 4 Oct 2012 13:32:30 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6B9B21F8733 for ; Thu, 4 Oct 2012 13:32:29 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so533644lam.31 for ; Thu, 04 Oct 2012 13:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=o85cBLjetzp3VN2UhhEVUF2J0+isOmL4/9zv5oZlGbA=; b=SOcWF/2uXgBvKF4a4enu+RoUqClVdL2F9hG8y301f/UVBHM1T96EWDHDLICHQNLzXV hbiRnSIwKbFjnf8rJjIqmaHYlA4XajFtBG7SnBYDssatrRZi3KPL6UIE0wLLPIrRupcd Q9N8r71VVMQkKU+gTlX23WC/rObyAdmbdrNLVkEqpOtj27s8LC6nLwj+NqMXzCrrtPD4 O/FPcsn5wla+kmygjZiLNNI18O+j7EGlkww0oEVMoc2fNkIZn7oFamyc12yl79RJ4EuN ioPwKiuaFuKtMgyyDquZ5hVCu5OcH51+lRfkk/8h2dW7E3sMB6nqplF1wAOrnU26PVmP 5NRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=o85cBLjetzp3VN2UhhEVUF2J0+isOmL4/9zv5oZlGbA=; b=SUL8I2uH9gUwQ/dliBA9VB4v9NqBb75m+GSZLTWX0HL5q399lw0rX58ODUlpVDzJPC ldXxvg5y08MMJIDFga3FN5+3/Ce1ErWmP1+34uHUQInWAvahoryA1+XgX/QqkqvIE8qV yDP9Z0m/8a5sutR0milp9yWwhI3qX5/nzsP6h70fEyJQESLmPh7qdqVlj8qs0aydHl5Q TRdNM/Db4zc8t664TezjkqeICAnnlLU9J5vLECCDQUObUC8zViyXHyIMdLQQumVDR7nu Ae0R7hXAHD7fUzLT6hU4x+TN5FnE94b+YsT31T+mPc0ZhphbnkGNbZOGs138YZMrSzpd 3hiw== Received: by 10.112.29.104 with SMTP id j8mr3118312lbh.127.1349382748516; Thu, 04 Oct 2012 13:32:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.102.201 with HTTP; Thu, 4 Oct 2012 13:32:08 -0700 (PDT) From: KK Date: Thu, 4 Oct 2012 13:32:08 -0700 Message-ID: To: opsec@ietf.org Content-Type: multipart/alternative; boundary=f46d04016a316432a204cb41a767 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm7SjrgBtULuIj4v/qMbpEmRg+VjRP0HZZxs9q85Tcrl/MfrJFoaXWZb7X5By3Fs3j0331Cbeh58Y3EH4jjYr55ZB4MGV70WQMP/bziNBz610eUW54ZmawX6JXmt5ljb6Jo0P0de0tOXnv/r/gG51jeh0JvQuhBpA2QsObI1xRBOqu7bFaw5xI6UhMFVZ89WPfL9Ctq Subject: [OPSEC] FYI: opsec - Requested session has been scheduled for IETF 85 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 20:32:35 -0000 --f46d04016a316432a204cb41a767 Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: "IETF Secretariat" Date: Thu, Oct 4, 2012 at 1:00 PM Subject: opsec - Requested session has been scheduled for IETF 85 To: kk@google.com Cc: opsec-ads@tools.ietf.org, warren@kumari.net, gvandeve@cisco.com, kk@google.com, wlo@amsl.com Dear KK Chittimaneni, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. opsec Session 1 (2:00:00) Friday, Morning Session I 0900-1100 Room Name: Salon C --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Area Name: Session Requester: Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: v6ops Second Priority: 6man Third Priority: dane Special Requests: Remote participation is expected --------------------------------------------------------- --f46d04016a316432a204cb41a767 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


---------- Fo= rwarded message ----------
From: "IET= F Secretariat" <agenda@ietf.org>
Date: Thu, Oct 4, 2012 at 1:00 PM
Subject: opsec - Requested session has= been scheduled for IETF 85
To: kk@google.com
Cc: opsec-ads@tools.ietf.org, warren@kumari.net, gvandeve@cisco.com, kk@google.com, wlo@amsl.com


Dear KK Chittimaneni,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

opsec Session 1 (2:00:00)
=A0 =A0 Friday, Morning Session I 0900-1100
=A0 =A0 Room Name: Salon C
=A0 =A0 ---------------------------------------------



Request Information:


---------------------------------------------------------
Working Group Name:
Area Name:
Session Requester:

Number of Sessions: 1
Length of Session(s): =A02 Hours
Number of Attendees: 100
Conflicts to Avoid:
=A0First Priority: v6ops
=A0Second Priority: 6man
=A0Third Priority: dane


Special Requests:
=A0 Remote participation is expected
---------------------------------------------------------


--f46d04016a316432a204cb41a767-- From brian.e.carpenter@gmail.com Sat Oct 6 06:49:24 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1071B21F8634 for ; Sat, 6 Oct 2012 06:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.566 X-Spam-Level: X-Spam-Status: No, score=-103.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1Ksoct5xvy0 for ; Sat, 6 Oct 2012 06:49:23 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7BB21F8630 for ; Sat, 6 Oct 2012 06:49:23 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7022772iec.31 for ; Sat, 06 Oct 2012 06:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6rYtDYf7Mk8lEAnSyL1K1FQkulgK80QQHnOIg5LDfus=; b=wlr1GbQz8DX+gSHOawh1hC+3aVK6zD6XRlE/H13umlUN1UbBBWjSK7MqiKhCrP3Zfm WAJe7jCJdrnpneRHuU3hfnWOWMagxiROA3MKs4OTbWAMkw9QGpsrPbgxOfmdV35EXTE+ rceJimwArEYl1cTRXm2Tw1JPpbdkcwl9h9lSrPs98OU+pQYOmia5kDSfH4RfDX0RWW3G 3ZWHl8vyrsb85JhpuJdm9JEkNdr5zut5kErFX2aFUslXCpj/9H51pIaxiDga5/fk/ytO AS0dLCdbH0xSnqMYZcX7eUljfoLbtlvKIlbxb6LFI9eaQ7a44+gTo5x3eRfe/iJd6Jme dNsw== Received: by 10.50.186.132 with SMTP id fk4mr1514785igc.41.1349531362913; Sat, 06 Oct 2012 06:49:22 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id 7sm3013554igh.0.2012.10.06.06.49.21 (version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 06:49:22 -0700 (PDT) Message-ID: <507036EB.5030409@gmail.com> Date: Sat, 06 Oct 2012 14:49:31 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: draft-ietf-opsec-v6@tools.ietf.org, opsec@ietf.org References: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> In-Reply-To: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 13:49:24 -0000 Hi, A few comments. I expect I will have more when the TBD sections are written. I am not on the opsec list. > This document complements [RFC4942] by listing all security issues That is a remarkable claim ;-). I think you mean This document complements [RFC4942] by listing all known security issues > 3.1. External Security Considerations: ... > o Accept certain ICMPv6 messages to allow proper operation of ND and > PMTUD, see also [RFC4890] This seems a very incomplete summary of the message of RFC 4890, which has a full analysis and recommendations. In fact (IMHO) it should be a BCP, since the correct behaviour is required for connectivity to work. > o Filter specific extension headers, where possible Please consider citing draft-carpenter-6man-ext-transmit, which discusses what firewalls need to do about extension headers. Also - why doesn't this section refer to RFC 4864, which is largely about external security considerations? > 5. Residential Users Security Considerations ... > If the Residential Gateway has IPv6 connectivity, [RFC6204] defines > the requirements of an IPv6 CPE Please update to 6204bis. Regards Brian Carpenter From merike@doubleshotsecurity.com Sat Oct 6 08:37:15 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC9A21F851A for ; Sat, 6 Oct 2012 08:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvsb72+N78br for ; Sat, 6 Oct 2012 08:37:14 -0700 (PDT) Received: from b.mail.sonic.net (b.mail.sonic.net [64.142.19.5]) by ietfa.amsl.com (Postfix) with ESMTP id D90B621F8516 for ; Sat, 6 Oct 2012 08:37:13 -0700 (PDT) Received: from dhcp-2.yoyodyne.com (DHCP-2.Yoyodyne.com [216.129.107.49]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id q96FbACY006467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Oct 2012 08:37:11 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Merike Kaeo In-Reply-To: <507036EB.5030409@gmail.com> Date: Sat, 6 Oct 2012 08:37:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> <507036EB.5030409@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: opsec@ietf.org, draft-ietf-opsec-v6@tools.ietf.org Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 15:37:15 -0000 Appreciate the review and initial comments....some replies embedded = below... On Oct 6, 2012, at 6:49 AM, Brian E Carpenter wrote: > Hi, >=20 > A few comments. I expect I will have more when the TBD sections are = written. > I am not on the opsec list. >=20 >> This document complements [RFC4942] by listing all security issues >=20 > That is a remarkable claim ;-). I think you mean >=20 > This document complements [RFC4942] by listing all known security = issues Yes, some word smithing still required everywhere since the intent is to = give enough input to operators to ensure this document gives definitive guidelines but also points to the = RFCs that detail all the specifics. We will edit this section. >=20 >> 3.1. External Security Considerations: > ... >> o Accept certain ICMPv6 messages to allow proper operation of ND = and >> PMTUD, see also [RFC4890] >=20 > This seems a very incomplete summary of the message of RFC 4890, which = has > a full analysis and recommendations. In fact (IMHO) it should be a = BCP, > since the correct behaviour is required for connectivity to work. Will add some wording here as well to be a bit more complete. >=20 >> o Filter specific extension headers, where possible >=20 > Please consider citing draft-carpenter-6man-ext-transmit, which = discusses > what firewalls need to do about extension headers. >=20 > Also - why doesn't this section refer to RFC 4864, which is largely = about > external security considerations? Probably simply an oversight which I'm happy you have pointed out. Will = look into this. >=20 >> 5. Residential Users Security Considerations > ... >> If the Residential Gateway has IPv6 connectivity, [RFC6204] defines >> the requirements of an IPv6 CPE >=20 > Please update to 6204bis. Yes. - merike >=20 > Regards > Brian Carpenter >=20 >=20 >=20 >=20 From fgont@si6networks.com Sat Oct 6 08:55:54 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE0D21F8527 for ; Sat, 6 Oct 2012 08:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mEK5tI4++nO for ; Sat, 6 Oct 2012 08:55:54 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF2321F84FE for ; Sat, 6 Oct 2012 08:55:54 -0700 (PDT) Received: from cust-115-144-109-94.dyn.as47377.net ([94.109.144.115] helo=[192.168.1.119]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TKWjG-00012H-4y; Sat, 06 Oct 2012 17:55:50 +0200 Message-ID: <50705483.7050209@si6networks.com> Date: Sat, 06 Oct 2012 17:55:47 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> <507036EB.5030409@gmail.com> In-Reply-To: <507036EB.5030409@gmail.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, draft-ietf-opsec-v6@tools.ietf.org Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 15:55:54 -0000 On 10/06/2012 03:49 PM, Brian E Carpenter wrote: >> o Filter specific extension headers, where possible > > Please consider citing draft-carpenter-6man-ext-transmit, which discusses > what firewalls need to do about extension headers. Wasn't aware about this I-D: 1) What's the plan for it? 2) It should probably reference draft-ietf-6man-oversized-header-chain, since it means that you can safely drop first-fragments that fail to include the entire IPv6 header chain. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From brian.e.carpenter@gmail.com Sat Oct 6 14:16:28 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC8E21F846C for ; Sat, 6 Oct 2012 14:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.568 X-Spam-Level: X-Spam-Status: No, score=-103.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pEJeBo0VVFu for ; Sat, 6 Oct 2012 14:16:28 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1304B21F8460 for ; Sat, 6 Oct 2012 14:16:28 -0700 (PDT) Received: by mail-ie0-f172.google.com with SMTP id 9so7585534iec.31 for ; Sat, 06 Oct 2012 14:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=yeRdD/8kC0Xs1X0bqGlFbL3Dw7oHcuS7mAqvW1eClCc=; b=GJf/pq+qOPyc6Ur/wEqnQAEXc5iWZ7tBH+3okaCQgdqNG9PJ0TH3UsZt6eNmpdyh5Z ds5uOgJ+tjLkobtbUXAeIxT+MbUJLfXmuenmpmcVY9iXyUZ0i4ZseQpFnvWkyfo0dbBI 5ZW5H3pCPbQC4y98+k+jtOuwUtHRKbkY0cuIQBEZU63XfZTzHDWd1TmlQmvHYMPgr/xh 7L8Qjzl8evhZ6MYeuUPZXvXYARl2GyVcNiVW9PxXd9ndA1E4IzA0jJvBY7bYh1X37aEQ dLTgV3C4ocIGzMcRXRgdYkZUMI/dbjuTDl0fuyGVsEoNIRekRDgd4fOGZns8Aksb51yS tfqA== Received: by 10.50.156.232 with SMTP id wh8mr4099619igb.56.1349558187549; Sat, 06 Oct 2012 14:16:27 -0700 (PDT) Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id bp8sm3855819igb.12.2012.10.06.14.16.26 (version=SSLv3 cipher=OTHER); Sat, 06 Oct 2012 14:16:27 -0700 (PDT) Message-ID: <50709FB4.9020305@gmail.com> Date: Sat, 06 Oct 2012 22:16:36 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fernando Gont References: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> <507036EB.5030409@gmail.com> <50705483.7050209@si6networks.com> In-Reply-To: <50705483.7050209@si6networks.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, draft-ietf-opsec-v6@tools.ietf.org Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 21:16:29 -0000 Hi Fernando, On 06/10/2012 16:55, Fernando Gont wrote: > On 10/06/2012 03:49 PM, Brian E Carpenter wrote: >>> o Filter specific extension headers, where possible >> Please consider citing draft-carpenter-6man-ext-transmit, which discusses >> what firewalls need to do about extension headers. > > Wasn't aware about this I-D: > > 1) What's the plan for it? We've requested a slot in 6man at the Atlanta IETF. Obviously, if it moves forward, it will also need security review. > > 2) It should probably reference draft-ietf-6man-oversized-header-chain, > since it means that you can safely drop first-fragments that fail to > include the entire IPv6 header chain. I will note that for the next version, thanks. Brian > > Cheers, From fgont@si6networks.com Sat Oct 6 14:25:07 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D91F721F84B9 for ; Sat, 6 Oct 2012 14:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvpVwq9mj8un for ; Sat, 6 Oct 2012 14:25:07 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBDB21F84B6 for ; Sat, 6 Oct 2012 14:25:07 -0700 (PDT) Received: from cust-115-144-109-94.dyn.as47377.net ([94.109.144.115] helo=[192.168.1.119]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TKbrq-0001Ir-Hd; Sat, 06 Oct 2012 23:25:02 +0200 Message-ID: <5070A1AD.9010906@si6networks.com> Date: Sat, 06 Oct 2012 23:25:01 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: Brian E Carpenter References: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> <507036EB.5030409@gmail.com> <50705483.7050209@si6networks.com> <50709FB4.9020305@gmail.com> In-Reply-To: <50709FB4.9020305@gmail.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: opsec@ietf.org, draft-ietf-opsec-v6@tools.ietf.org Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 21:25:08 -0000 On 10/06/2012 11:16 PM, Brian E Carpenter wrote: >> 1) What's the plan for it? > > We've requested a slot in 6man at the Atlanta IETF. Obviously, if it moves > forward, it will also need security review. Good. -- I'd be willing to review. Please let me know if you'd prefer my review before or after the next IETF. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rdobbins@arbor.net Sat Oct 6 19:11:37 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCF821F84D5 for ; Sat, 6 Oct 2012 19:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXXwjLcV8bxv for ; Sat, 6 Oct 2012 19:11:36 -0700 (PDT) Received: from gwo1.mbox.net (gateout01.mbox.net [165.212.64.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD2E21F84C5 for ; Sat, 6 Oct 2012 19:11:36 -0700 (PDT) Received: from gwo1.mbox.net (localhost [127.0.0.1]) by gwo1.mbox.net (Postfix) with ESMTP id 8A1CDE002A73; Sun, 7 Oct 2012 02:11:35 +0000 (UTC) X-USANET-Received: from gwo1.mbox.net [127.0.0.1] by gwo1.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 930qJgcLI1632Mo1; Sun, 07 Oct 2012 02:11:34 -0000 Received: from S1HUB8.EXCHPROD.USA.NET [165.212.120.254] by gwo1.mbox.net via smtad (C8.MAIN.3.75S.2) with ESMTPS id XID161qJgcLI2654Xo1; Sun, 07 Oct 2012 02:11:34 -0000 X-USANET-Source: 165.212.120.254 IN rdobbins@arbor.net S1HUB8.EXCHPROD.USA.NET X-USANET-MsgId: XID161qJgcLI2654Xo1 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by S1HUB8.EXCHPROD.USA.NET ([10.120.220.38]) with mapi; Sun, 7 Oct 2012 02:11:34 +0000 From: "Dobbins, Roland" To: "draft-ietf-opsec-v6@tools.ietf.org" Date: Sun, 7 Oct 2012 02:11:32 +0000 Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt Thread-Index: Ac2kMRK0TO3ZcJYgSFaV0sM2B4aOJA== Message-ID: References: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> <507036EB.5030409@gmail.com> <50705483.7050209@si6networks.com> In-Reply-To: <50705483.7050209@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: opsec wg mailing list Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 02:11:37 -0000 On Oct 6, 2012, at 10:55 PM, Fernando Gont wrote: > 2) It should probably reference draft-ietf-6man-oversized-header-chain, > since it means that you can safely drop first-fragments that fail to > include the entire IPv6 header chain. We don't necessarily know what a 'first-fragment' is in a given communicati= ons session, given unpredictability in order of arrival. 'Initial fragment= ' would probably be a better choice (vs. non-initial fragment). ;> ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From gvandeve@cisco.com Sun Oct 7 02:29:43 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D8521F8448; Sun, 7 Oct 2012 02:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.705 X-Spam-Level: X-Spam-Status: No, score=-10.705 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBTNpm6h7xGS; Sun, 7 Oct 2012 02:29:41 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9125B21F850D; Sun, 7 Oct 2012 02:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6043; q=dns/txt; s=iport; t=1349602181; x=1350811781; h=from:to:subject:date:message-id:mime-version; bh=/FZwVRamVmIyYPjDJJmstMAjhyIjlmGtnt58BvHt0Jg=; b=eeR5RH+m9LZ7HaK7l0DwsvtLHATWIzMkPdMZ2dJn4tW4NMXB9b5HY4ha ZZB2lnsIw0j0qz/3YGVIzEf+nCrtKKm9a4SHnBWHQPfSShk4GPKVt+tDu 7IljCdSrzKvBp/OGvhJjkaQzTwrHYxXDwZRK5ajml9gBCCFIWyfWSjv4I M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAA5LcVCtJV2d/2dsb2JhbABFgku8V4EIgiIBBBIBGl4BKlYmAQQBGgEZh2MLmg2fCJB/YAOXAI0wgWmCbYIX X-IronPort-AV: E=Sophos;i="4.80,547,1344211200"; d="scan'208,217";a="129075717" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 07 Oct 2012 09:29:41 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q979TeSO022435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Oct 2012 09:29:40 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Sun, 7 Oct 2012 04:29:40 -0500 From: "Gunter Van de Velde (gvandeve)" To: "v6ops v6ops WG (v6ops@ietf.org)" , "opsec@ietf.org" Thread-Topic: Passive IP addresses - 2th iteration Thread-Index: Ac2kbgMQYxCCEpPZSqa8dHdhP5jyCQ== Date: Sun, 7 Oct 2012 09:29:40 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.95.225] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19250.001 x-tm-as-result: No--32.857400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B2408182EDExmbalnx12ciscoc_" MIME-Version: 1.0 Subject: [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 09:29:43 -0000 --_000_67832B1175062E48926BF3CB27C49B2408182EDExmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, I am picking the ball up again wrt Passive IP addresses, particular in the = light of all the discussions around the tools.ietf.org/html/draft-ietf-opse= c-lla-only IP addresses. (http://www.ietf.org/id/draft-baker-opsec-passive-ip-address-01.txt) One of the considerations regarding usage of LLA-Only is that network visib= ility is undermined for a part. This is exactly one of the things that Passive addresses can aid with. It p= rovides network visilbility, while still protecting the network from some e= xternal influences. So in a nutshell: Q) What is a passive address? A) any kind of address you configure on a device or interface Q) is there need for a new address type specified by IANA A) No Q) what makes an address a passive address A) during configuration of that address on an interface/device you specify = for example: ip address foo 'passive' Q) what does the passive keyword result into A) If the recipient device receives an IP packet with this passive address = in the destination address and is destined for this device, then the packet= will be dropped. However, when the device gets for example a packet with T= TL expired (for trace-route) then this passive address could be used as the= source address Q) can a passive address be used to build a session with? A) nope, it only accommodates unidirectional traffic G/ --_000_67832B1175062E48926BF3CB27C49B2408182EDExmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG,

 

I am picking the ball up again wrt Passive IP addres= ses, particular in the light of all the discussions around the tools.ietf.org/html/draft-ietf-opsec-lla-only IP addresses.

(http://www.ietf.org/id/draft-baker-opsec-passive-ip= -address-01.txt)

 

One of the considerations regarding usage of LLA-Onl= y is that network visibility is undermined for a part.

This is exactly one of the things that Passive addre= sses can aid with. It provides network visilbility, while still protecting = the network from some external influences.

 

So in a nutshell:

Q) What is a passive address?

A) any kind of address you configure on a device or = interface

 

Q) is there need for a new address type specified by= IANA

A) No

 

Q) what makes an address a passive address

A) during configuration of that address on an interf= ace/device you specify for example: ip address foo ‘passive’

 

Q) what does the passive keyword result into

A) If the recipient device receives an IP packet wit= h this passive address in the destination address and is destined for this = device, then the packet will be dropped. However, when the device gets for = example a packet with TTL expired (for trace-route) then this passive address could be used as the source ad= dress

 

Q) can a passive address be used to build a session = with?

A) nope, it only accommodates unidirectional traffic=

 

 

G/

--_000_67832B1175062E48926BF3CB27C49B2408182EDExmbalnx12ciscoc_-- From fgont@si6networks.com Sun Oct 7 03:16:50 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E34121F851A for ; Sun, 7 Oct 2012 03:16: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=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzyf2KKnhp7Q for ; Sun, 7 Oct 2012 03:16:50 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id E369221F850D for ; Sun, 7 Oct 2012 03:16:49 -0700 (PDT) Received: from cust-115-144-109-94.dyn.as47377.net ([94.109.144.115] helo=[192.168.1.119]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TKnub-0006Xo-I2; Sun, 07 Oct 2012 12:16:41 +0200 Message-ID: <50715688.7000500@si6networks.com> Date: Sun, 07 Oct 2012 12:16:40 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Dobbins, Roland" References: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> <507036EB.5030409@gmail.com> <50705483.7050209@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec wg mailing list , "draft-ietf-opsec-v6@tools.ietf.org" Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:16:50 -0000 On 10/07/2012 04:11 AM, Dobbins, Roland wrote: >> 2) It should probably reference >> draft-ietf-6man-oversized-header-chain, since it means that you can >> safely drop first-fragments that fail to include the entire IPv6 >> header chain. > > We don't necessarily know what a 'first-fragment' is in a given > communications session, given unpredictability in order of arrival. > 'Initial fragment' would probably be a better choice (vs. non-initial > fragment). English as second language here, so the difference is not that big for me. Anyway, I was referring to packets containing a Fragment Header with the FO=0. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rdobbins@arbor.net Sun Oct 7 03:24:06 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EB621F84F3 for ; Sun, 7 Oct 2012 03:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvkKSfi08S32 for ; Sun, 7 Oct 2012 03:24:05 -0700 (PDT) Received: from gwo1.mbox.net (gateout01.mbox.net [165.212.64.21]) by ietfa.amsl.com (Postfix) with ESMTP id A8E4121F846E for ; Sun, 7 Oct 2012 03:24:05 -0700 (PDT) Received: from gwo1.mbox.net (localhost [127.0.0.1]) by gwo1.mbox.net (Postfix) with ESMTP id C2C1EE0287E9; Sun, 7 Oct 2012 10:24:04 +0000 (UTC) X-USANET-Received: from gwo1.mbox.net [127.0.0.1] by gwo1.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 476qJgkyc5232Mo1; Sun, 07 Oct 2012 10:24:02 -0000 Received: from S1HUB6.EXCHPROD.USA.NET [165.212.120.254] by gwo1.mbox.net via smtad (C8.MAIN.3.75S.2) with ESMTPS id XID458qJgkyc2862Xo1; Sun, 07 Oct 2012 10:24:02 -0000 X-USANET-Source: 165.212.120.254 IN rdobbins@arbor.net S1HUB6.EXCHPROD.USA.NET X-USANET-MsgId: XID458qJgkyc2862Xo1 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by S1HUB6.EXCHPROD.USA.NET ([10.120.220.36]) with mapi; Sun, 7 Oct 2012 10:24:01 +0000 From: "Dobbins, Roland" To: "draft-ietf-opsec-v6@tools.ietf.org" Date: Sun, 7 Oct 2012 10:23:59 +0000 Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt Thread-Index: Ac2kdd74VdZgJ4GgQwWAr7hewwMmjQ== Message-ID: <68379C01-092B-47C7-A0BE-3E5AF36B2230@arbor.net> References: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> <507036EB.5030409@gmail.com> <50705483.7050209@si6networks.com> <50715688.7000500@si6networks.com> In-Reply-To: <50715688.7000500@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: opsec wg mailing list Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:24:06 -0000 On Oct 7, 2012, at 5:16 PM, Fernando Gont wrote: > English as second language here, so the difference is not that big for me= . No linguistic criticism intended, Fernando; in general, folks tend to refer= to the 'first fragment', but there're really only initial fragments and no= n-initial fragments. It's a small but important conceptual difference, IMH= O, that's all. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins@arbor.net Sun Oct 7 03:27:11 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99B221F8528; Sun, 7 Oct 2012 03:27:11 -0700 (PDT) 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=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYMt7YFI52tr; Sun, 7 Oct 2012 03:27:11 -0700 (PDT) Received: from gwo3.mbox.net (gateout03.mbox.net [165.212.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1FD21F846E; Sun, 7 Oct 2012 03:27:11 -0700 (PDT) Received: from gwo3.mbox.net (localhost [127.0.0.1]) by gwo3.mbox.net (Postfix) with ESMTP id 0E3AFE0AE56A; Sun, 7 Oct 2012 10:27:10 +0000 (UTC) X-USANET-Received: from gwo3.mbox.net [127.0.0.1] by gwo3.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 332qJgkbH1024Mo3; Sun, 07 Oct 2012 10:27:07 -0000 Received: from S1HUB3.EXCHPROD.USA.NET [165.212.120.254] by gwo3.mbox.net via smtad (C8.MAIN.3.75S.2) with ESMTPS id XID169qJgkbH2085Xo3; Sun, 07 Oct 2012 10:27:07 -0000 X-USANET-Source: 165.212.120.254 IN rdobbins@arbor.net S1HUB3.EXCHPROD.USA.NET X-USANET-MsgId: XID169qJgkbH2085Xo3 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by S1HUB3.EXCHPROD.USA.NET ([10.120.220.33]) with mapi; Sun, 7 Oct 2012 10:27:07 +0000 From: "Dobbins, Roland" To: opsec wg mailing list Date: Sun, 7 Oct 2012 10:27:05 +0000 Thread-Topic: [OPSEC] Passive IP addresses - 2th iteration Thread-Index: Ac2kdk0alnjffXdRS26mTlyUp1/kLg== Message-ID: <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:27:12 -0000 On Oct 7, 2012, at 4:29 PM, Gunter Van de Velde (gvandeve) wrote: > A) If the recipient device receives an IP packet with this passive addres= s in the destination address and is destined for this device, then the pack= et will be dropped. What's the advantage to this over ACLs? It seems just another way to fragm= ent (pardon the pun, heh) network access policy even further than it alread= y is. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From gvandeve@cisco.com Sun Oct 7 03:32:45 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D587721F853E; Sun, 7 Oct 2012 03:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m9P4d6UKumV; Sun, 7 Oct 2012 03:32:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id E4AC321F850D; Sun, 7 Oct 2012 03:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1629; q=dns/txt; s=iport; t=1349605965; x=1350815565; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xZLF/28IZeouxdaSg7BMTSlz/7K8Zk+LngchwUdlgyo=; b=nBt00qz6c4Rz/F+lKF2RItPqLdeeclGGqe1tEDOYhVKmKBfAQb16Y8lu 18bY6s/dtaOuZx1ixuOF6tTttBXFqJmGVHQ/lFFMFzNiD/edOJ7W7U6ey utXQbHDQOn03FdIar1Ff3xBvyM3KbRcRWen3yTy9ssiZ7Xw9tmwZw6XOd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGJZcVCtJV2d/2dsb2JhbABFvyKBCIIgAQEBAwEBAQEPASc0CwUHBAIBCBEEAQELFAkHJwsUCQgBAQQBDQUIGoddBguaA58Di0+FMGADpDCBaYJtghc X-IronPort-AV: E=Sophos;i="4.80,547,1344211200"; d="scan'208";a="129110056" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 07 Oct 2012 10:32:44 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q97AWiSM017067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Oct 2012 10:32:44 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Sun, 7 Oct 2012 05:32:44 -0500 From: "Gunter Van de Velde (gvandeve)" To: "Dobbins, Roland" , opsec wg mailing list Thread-Topic: [OPSEC] Passive IP addresses - 2th iteration Thread-Index: Ac2kbgMQYxCCEpPZSqa8dHdhP5jyCQAMjGqAAApymcA= Date: Sun, 7 Oct 2012 10:32:43 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2408183F05@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> In-Reply-To: <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.95.225] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19250.001 x-tm-as-result: No--35.468800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:32:46 -0000 Edge ACL tend to be wrong after a while (too much operation involved etc...= ) This is just another way to shield the infrastructure.=20 Often within a network non-LLA's are used for traffic path visibility, or f= or trace-routes. Passive addresses will in that case reduce the attack vector as they are us= eless as a destination address, because the recipient target box will drop = any packet received where this address is used as destination address. It does not mean that you should not use perimeter ACL or FW's at all. That is still good practice. G/ -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of D= obbins, Roland Sent: 07 October 2012 12:27 To: opsec wg mailing list Cc: v6ops v6ops WG (v6ops@ietf.org) Subject: Re: [OPSEC] Passive IP addresses - 2th iteration On Oct 7, 2012, at 4:29 PM, Gunter Van de Velde (gvandeve) wrote: > A) If the recipient device receives an IP packet with this passive addres= s in the destination address and is destined for this device, then the pack= et will be dropped. What's the advantage to this over ACLs? It seems just another way to fragm= ent (pardon the pun, heh) network access policy even further than it alread= y is. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From fgont@si6networks.com Sun Oct 7 03:35:28 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13FE21F8518 for ; Sun, 7 Oct 2012 03:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9N6kYNIse1OI for ; Sun, 7 Oct 2012 03:35:28 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 39D1921F8513 for ; Sun, 7 Oct 2012 03:35:28 -0700 (PDT) Received: from cust-115-144-109-94.dyn.as47377.net ([94.109.144.115] helo=[192.168.1.119]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TKoCf-00074N-DM; Sun, 07 Oct 2012 12:35:21 +0200 Message-ID: <50715AE6.9090004@si6networks.com> Date: Sun, 07 Oct 2012 12:35:18 +0200 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120912 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Dobbins, Roland" References: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> <507036EB.5030409@gmail.com> <50705483.7050209@si6networks.com> <50715688.7000500@si6networks.com> <68379C01-092B-47C7-A0BE-3E5AF36B2230@arbor.net> In-Reply-To: <68379C01-092B-47C7-A0BE-3E5AF36B2230@arbor.net> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: opsec wg mailing list , "draft-ietf-opsec-v6@tools.ietf.org" Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:35:28 -0000 On 10/07/2012 12:23 PM, Dobbins, Roland wrote: > > On Oct 7, 2012, at 5:16 PM, Fernando Gont wrote: > >> English as second language here, so the difference is not that big >> for me. > > No linguistic criticism intended, Fernando; I was actually *encouraging* them :-), since I might use terms or expressions that might sound incorrect to a native English-speaking person. > in general, folks tend to > refer to the 'first fragment', but there're really only initial > fragments and non-initial fragments. I guess the order (first, second, etc.) could refer to the order in which the fragments are received, or the order that they "occupy" in the original fragment? e.g., it's easier to refer to each of the fragments in a, say, four-fragment packet as "{first, second, third, fourth} fragment" as oposed to....mm.. initial fragment, last fragment, and... what about the two "middle" fragments? P.S.: Discussion this one is important, since we're about to ship draft-ietf-6man-ipv6-atomic-fragments... Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From rdobbins@arbor.net Sun Oct 7 03:40:09 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC4321F8545 for ; Sun, 7 Oct 2012 03:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZla+VB5sB3r for ; Sun, 7 Oct 2012 03:40:08 -0700 (PDT) Received: from gwo2.mbox.net (gateout02.mbox.net [165.212.64.22]) by ietfa.amsl.com (Postfix) with ESMTP id CE91D21F852D for ; Sun, 7 Oct 2012 03:40:08 -0700 (PDT) Received: from gwo2.mbox.net (localhost [127.0.0.1]) by gwo2.mbox.net (Postfix) with ESMTP id E60FBE01D39C; Sun, 7 Oct 2012 10:40:05 +0000 (UTC) X-USANET-Received: from gwo2.mbox.net [127.0.0.1] by gwo2.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 358qJgkOD9808Mo2; Sun, 07 Oct 2012 10:40:03 -0000 Received: from S1HUB2.EXCHPROD.USA.NET [165.212.120.254] by gwo2.mbox.net via smtad (C8.MAIN.3.75S.2) with ESMTPS id XID611qJgkOD4102Xo2; Sun, 07 Oct 2012 10:40:03 -0000 X-USANET-Source: 165.212.120.254 IN rdobbins@arbor.net S1HUB2.EXCHPROD.USA.NET X-USANET-MsgId: XID611qJgkOD4102Xo2 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by S1HUB2.EXCHPROD.USA.NET ([10.120.220.32]) with mapi; Sun, 7 Oct 2012 10:40:03 +0000 From: "Dobbins, Roland" To: opsec wg mailing list Date: Sun, 7 Oct 2012 10:40:02 +0000 Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt Thread-Index: Ac2keBv9LvHLLg+JQDu7xT2WzWHneg== Message-ID: References: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> <507036EB.5030409@gmail.com> <50705483.7050209@si6networks.com> <50715688.7000500@si6networks.com> <68379C01-092B-47C7-A0BE-3E5AF36B2230@arbor.net> <50715AE6.9090004@si6networks.com> In-Reply-To: <50715AE6.9090004@si6networks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-opsec-v6@tools.ietf.org" Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:40:09 -0000 On Oct 7, 2012, at 5:35 PM, Fernando Gont wrote: > e.g., it's easier to refer to each of the fragments in a, say, four-fragm= ent packet as "{first, second, third, fourth} fragment" as > oposed to....mm.. initial fragment, last fragment, and... what about the = two "middle" fragments? >From a purely network engineering standpoint, there are only initial fragme= nts and non-initial fragments. Apart from that distinction, ordering reall= y only applies on the relevant endpoints. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From rdobbins@arbor.net Sun Oct 7 03:41:35 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13B021F8550; Sun, 7 Oct 2012 03:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WggCFlbZG6d7; Sun, 7 Oct 2012 03:41:34 -0700 (PDT) Received: from gwo2.mbox.net (gateout02.mbox.net [165.212.64.22]) by ietfa.amsl.com (Postfix) with ESMTP id 722ED21F852D; Sun, 7 Oct 2012 03:41:34 -0700 (PDT) Received: from gwo2.mbox.net (localhost [127.0.0.1]) by gwo2.mbox.net (Postfix) with ESMTP id 0A09EE01D390; Sun, 7 Oct 2012 10:41:34 +0000 (UTC) X-USANET-Received: from gwo2.mbox.net [127.0.0.1] by gwo2.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 534qJgkpG2208Mo2; Sun, 07 Oct 2012 10:41:32 -0000 Received: from S1HUB4.EXCHPROD.USA.NET [165.212.120.254] by gwo2.mbox.net via smtad (C8.MAIN.3.75S.2) with ESMTPS id XID747qJgkpG2438Xo2; Sun, 07 Oct 2012 10:41:32 -0000 X-USANET-Source: 165.212.120.254 IN rdobbins@arbor.net S1HUB4.EXCHPROD.USA.NET X-USANET-MsgId: XID747qJgkpG2438Xo2 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by S1HUB4.EXCHPROD.USA.NET ([10.120.220.34]) with mapi; Sun, 7 Oct 2012 10:41:32 +0000 From: "Dobbins, Roland" To: opsec wg mailing list Date: Sun, 7 Oct 2012 10:41:31 +0000 Thread-Topic: [OPSEC] Passive IP addresses - 2th iteration Thread-Index: Ac2keFDOSoyUErhnQ4qGdq/LRivDxw== Message-ID: <64A6CFA9-D0BF-48FA-986C-747D08655B03@arbor.net> References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> <67832B1175062E48926BF3CB27C49B2408183F05@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2408183F05@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 10:41:35 -0000 On Oct 7, 2012, at 5:32 PM, Gunter Van de Velde (gvandeve) wrote: > Edge ACL tend to be wrong after a while (too much operation involved etc.= ..) Operational entropy applies to all forms of policy. > This is just another way to shield the infrastructure.=20 A potentially duplicative, confusing and unnecessary way, IMHO. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From gvandeve@cisco.com Sun Oct 7 04:50:26 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF4221F84F2; Sun, 7 Oct 2012 04:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.39 X-Spam-Level: X-Spam-Status: No, score=-10.39 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2t9Cq3xHtCe2; Sun, 7 Oct 2012 04:50:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF6621F84F1; Sun, 7 Oct 2012 04:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1402; q=dns/txt; s=iport; t=1349610625; x=1350820225; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pi1eWu8IGhBu8BVDV90ZAV64o0E1x1eAfxPwQ0SRPO0=; b=eNn4kdVoRN9O2zHF2qSHojLIRTnOBKA2j5ZLW+LfMFOhcERSZ3xsqpDR poSudWDmvDAINDxnj5W5lUVGRdzEGcNxKKu4y7/jq+9iGaA52V+/PzzFB VC9MG15E86AZRPLWOCzdSt77KhCvbjKZU/L+4N+eZN+6aOtMqXJ7Bqe6M Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEJscVCtJXHA/2dsb2JhbABFvyKBCIIgAQEBAwEBAQEPASc0CwUHBAIBCBEEAQELFAkHJwsUCQgBAQQBDQUIGoddBguaCp5/i08UhRxgA6QwgWmCbYFaPQ X-IronPort-AV: E=Sophos;i="4.80,547,1344211200"; d="scan'208";a="129083025" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 07 Oct 2012 11:50:25 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q97BoOG5018252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 7 Oct 2012 11:50:24 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.001; Sun, 7 Oct 2012 06:50:24 -0500 From: "Gunter Van de Velde (gvandeve)" To: "Dobbins, Roland" , opsec wg mailing list Thread-Topic: [OPSEC] Passive IP addresses - 2th iteration Thread-Index: Ac2kbgMQYxCCEpPZSqa8dHdhP5jyCQAMjGqAAApymcD//7BzgIAAQWzw Date: Sun, 7 Oct 2012 11:50:23 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B2408183F28@xmb-aln-x12.cisco.com> References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> <67832B1175062E48926BF3CB27C49B2408183F05@xmb-aln-x12.cisco.com> <64A6CFA9-D0BF-48FA-986C-747D08655B03@arbor.net> In-Reply-To: <64A6CFA9-D0BF-48FA-986C-747D08655B03@arbor.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.95.225] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19250.001 x-tm-as-result: No--37.031600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 11:50:26 -0000 I fairly do not see what ACL have to do with Passive addresses? They serve completely different goals (and are to some degree ortogonal). ACls should still be used where ever found usefull. Passive address can be = used where deemed usefull for device protection while still allowing limite= d troubleshooting within the network (traceroute, traps as most important o= nces). Please feel free to read the draft. G/ -----Original Message----- From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf Of D= obbins, Roland Sent: 07 October 2012 12:42 To: opsec wg mailing list Cc: v6ops v6ops WG (v6ops@ietf.org) Subject: Re: [OPSEC] Passive IP addresses - 2th iteration On Oct 7, 2012, at 5:32 PM, Gunter Van de Velde (gvandeve) wrote: > Edge ACL tend to be wrong after a while (too much operation involved etc.= ..) Operational entropy applies to all forms of policy. > This is just another way to shield the infrastructure.=20 A potentially duplicative, confusing and unnecessary way, IMHO. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec From rdobbins@arbor.net Sun Oct 7 05:36:46 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE9421F8569; Sun, 7 Oct 2012 05:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMEfPhQzewpG; Sun, 7 Oct 2012 05:36:45 -0700 (PDT) Received: from gwo1.mbox.net (gateout01.mbox.net [165.212.64.21]) by ietfa.amsl.com (Postfix) with ESMTP id E118621F8567; Sun, 7 Oct 2012 05:36:45 -0700 (PDT) Received: from gwo1.mbox.net (localhost [127.0.0.1]) by gwo1.mbox.net (Postfix) with ESMTP id C0CFDE037EE9; Sun, 7 Oct 2012 12:36:44 +0000 (UTC) X-USANET-Received: from gwo1.mbox.net [127.0.0.1] by gwo1.mbox.net via mtad (C8.MAIN.3.82G) with ESMTP id 881qJgmKQ4832Mo1; Sun, 07 Oct 2012 12:36:42 -0000 Received: from S1HUB5.EXCHPROD.USA.NET [165.212.120.254] by gwo1.mbox.net via smtad (C8.MAIN.3.75S.2) with ESMTPS id XID287qJgmKQ7646Xo1; Sun, 07 Oct 2012 12:36:42 -0000 X-USANET-Source: 165.212.120.254 IN rdobbins@arbor.net S1HUB5.EXCHPROD.USA.NET X-USANET-MsgId: XID287qJgmKQ7646Xo1 Received: from MBX14.EXCHPROD.USA.NET ([10.120.221.141]) by S1HUB5.EXCHPROD.USA.NET ([10.120.220.35]) with mapi; Sun, 7 Oct 2012 12:36:41 +0000 From: "Dobbins, Roland" To: opsec wg mailing list Date: Sun, 7 Oct 2012 12:36:39 +0000 Thread-Topic: [OPSEC] Passive IP addresses - 2th iteration Thread-Index: Ac2kiGblvyMjukGkS3WZEg2juaLEXw== Message-ID: <99755C4A-1B11-4B2D-9B2C-06688AF090E1@arbor.net> References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> <67832B1175062E48926BF3CB27C49B2408183F05@xmb-aln-x12.cisco.com> <64A6CFA9-D0BF-48FA-986C-747D08655B03@arbor.net> <67832B1175062E48926BF3CB27C49B2408183F28@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2408183F28@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Oct 2012 12:36:46 -0000 On Oct 7, 2012, at 6:50 PM, Gunter Van de Velde (gvandeve) wrote: > Passive address can be used where deemed usefull for device protection w= hile still allowing limited troubleshooting within the network (traceroute,= traps as most important onces). What you're describing is a policy function already encapsulated by ACLs. And in general, it seems to follow the deplorable trend of continuing to ov= erload IP addresses with more and more significance when a) they're already= grossly overloaded and b) we're supposedly going to a world of IPv6 addres= ses, which should imply *less* significance, not more. ----------------------------------------------------------------------- Roland Dobbins // Luck is the residue of opportunity and design. -- John Milton From gert@space.net Mon Oct 8 04:01:01 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA90621F8712 for ; Mon, 8 Oct 2012 04:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.418 X-Spam-Level: X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ez3Rb2JiEnyo for ; Mon, 8 Oct 2012 04:01:01 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3FA21F8711 for ; Mon, 8 Oct 2012 04:01:00 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id E5536F8CB6 for ; Mon, 8 Oct 2012 13:00:58 +0200 (CEST) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id B9360F8C9C for ; Mon, 8 Oct 2012 13:00:58 +0200 (CEST) Received: (qmail 54187 invoked by uid 1007); 8 Oct 2012 13:00:58 +0200 Date: Mon, 8 Oct 2012 13:00:58 +0200 From: Gert Doering To: "Gunter Van de Velde \(gvandeve\)" Message-ID: <20121008110058.GO13776@Space.Net> References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> <1FE17CAD-3FF3-4EB1-B556-96BEE9494FF9@arbor.net> <67832B1175062E48926BF3CB27C49B2408183F05@xmb-aln-x12.cisco.com> <64A6CFA9-D0BF-48FA-986C-747D08655B03@arbor.net> <67832B1175062E48926BF3CB27C49B2408183F28@xmb-aln-x12.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67832B1175062E48926BF3CB27C49B2408183F28@xmb-aln-x12.cisco.com> X-NCC-RegID: de.space User-Agent: Mutt/1.5.21 (2010-09-15) Cc: opsec wg mailing list , "v6ops v6ops WG \(v6ops@ietf.org\)" Subject: Re: [OPSEC] Passive IP addresses - 2th iteration X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 11:01:02 -0000 Hi, On Sun, Oct 07, 2012 at 11:50:23AM +0000, Gunter Van de Velde (gvandeve) wrote: > I fairly do not see what ACL have to do with Passive addresses? Well, I have to agree with Roland - a "passive IP address" would be one that has a "receive ACL", or "control plane policy with drop-all" or however a vendor calls that feature "do not accept packets for a certain IP address" attached to it. Don't confuse with transit ACLs. (Now, not all vendors ship useful implementations of rRACLs or CoPP today, but those wouldn't know what a passive IP address is either) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From kkumar@google.com Sun Oct 14 15:44:53 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE21F21F8462 for ; Sun, 14 Oct 2012 15:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.715 X-Spam-Level: X-Spam-Status: No, score=-102.715 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJaXQ0orJNRV for ; Sun, 14 Oct 2012 15:44:53 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9454821F8452 for ; Sun, 14 Oct 2012 15:44:52 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3375344lam.31 for ; Sun, 14 Oct 2012 15:44:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=I/W7vlG13J+vZtIOI0Vg3ca6vJkF32vTqb2OCJ27cn4=; b=O5VDTVQ1YZaL3I/hQcbx2UqRG1HSrwDipNF9XymMpFYaAY1QzMbAKJiMq60c14Fi5g +L+b8s47jy6vJIrhGdJ1emUzyY6kCWYKqIqOYx/SQSZ8Qp3NMs+yOwgrYOlNQ/unRkD3 jATL6b7VpVDgQVxVO09vSuvZLgE8s520nd0aJ1372iM+iaV8OJKEhekQUuMoALh8ykIK 4bE/4Kq5eRnfRGu8A1Y9xAd4lo0JB1sh5CNaXCBEqak94bhq6dn6FKTgt1KsahBO5j82 3q9jhYb55t6GkCbIvrFnMCAeuiV/VFDAV0rI6iSmOOXHDeSjD8zl18zW+qQ3KqBNyoK4 fyAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=I/W7vlG13J+vZtIOI0Vg3ca6vJkF32vTqb2OCJ27cn4=; b=BWlyukgvXF6fn9IM7QcRc1DOO1sxJGVkYFUIRC+YNi1E+7ET6pMK3OENMs+9mdgLRy bg+awyKJMAWGbw9pMk1AW5/COlN+U2v+CQb65cSPvm3gtNmnJyEEqJAC3laHIM97LRiB PxPfjq9UJUjMTKHxYm3yr6+VMwWDCrQsoSS7v+LW6HNhLPt2JuT9z/5o6uI4eTuZ1wD3 oANzYfHy0++a/R1n7WwuRmrPijZvoBIt9z8ZQgAiV44X1yeA8NCeSCwevhIlZLl6NNyF AULAx1thmPRMa49E5XwT95eZLHOuG45K07qfTyZxc43iFwXjUwDE5mdEWbiQNOaEZS4i MTEA== Received: by 10.152.108.66 with SMTP id hi2mr8486768lab.11.1350254691298; Sun, 14 Oct 2012 15:44:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.102.201 with HTTP; Sun, 14 Oct 2012 15:44:30 -0700 (PDT) From: KK Date: Sun, 14 Oct 2012 15:44:30 -0700 Message-ID: To: opsec@ietf.org Content-Type: multipart/alternative; boundary=bcaec54eecc83b2e9e04cc0cab58 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmp7rwSGueviFFKuGvELyI/plrJ8Hko6pHUXPVDEiWPdYW/9MmWSeY2aVlcOBn7borPewVcGXjz3uMZI7wbHsLJjWd2nh+vu8mv8C8UGdpFcccFA/y1Wp87UNGB7zyfmI8MgbTAgJ7qsONjqsCjdPXVF1kH+B7ey8W3S/BHFyobEwulczLkcR+MGmAd0pciG/bc4nsS Subject: [OPSEC] OPSEC IETF85 Call for Agenda Items X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 22:44:53 -0000 --bcaec54eecc83b2e9e04cc0cab58 Content-Type: text/plain; charset=ISO-8859-1 Dear All, If you have a draft you would like to discuss during IETF85, please send your request for agenda time to the opsec chairs. Please include in the request, the title and file name of the draft, the speakers name, and how much time you would need. We will prioritize drafts that are WG items, drafts that have been actively discussed on the list, and other individual submissions in that order. Please send in your agenda items to us by 22 October 2012. A few important dates to note for document submission: 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) submission by UTC 24:00 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 24:00 Regards, KK, Gunter, Warren --bcaec54eecc83b2e9e04cc0cab58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear All,

If you have a draft you would like = to discuss during IETF85, please send your request for agenda time to the o= psec chairs. Please include in the request, the title and file name of the = draft, the speakers name, and how much time you would need.

We will prioritize drafts that are WG items, drafts tha= t have been actively discussed on the list, and other individual submission= s in that order.

Please send in your agenda items = to us by 22 October 2012. A few important dates to note for document submis= sion:

=A0 2012-10-15 (Monday): Internet Draft Cut-off for ini= tial document (-00) submission by UTC 24:00
=A0 2012-10-22 (Monda= y): Internet Draft final submission cut-off by UTC 24:00

Regards,
KK, Gunter, Warren

--bcaec54eecc83b2e9e04cc0cab58-- From fgont@si6networks.com Mon Oct 15 11:52:01 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077D721F885D for ; Mon, 15 Oct 2012 11:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4TmLRt-P2l5 for ; Mon, 15 Oct 2012 11:52:00 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 5012821F8812 for ; Mon, 15 Oct 2012 11:52:00 -0700 (PDT) Received: from [186.134.17.185] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TNplc-0007G6-H9; Mon, 15 Oct 2012 20:51:56 +0200 Message-ID: <507C5B45.6080500@si6networks.com> Date: Mon, 15 Oct 2012 15:51:49 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "'opsec@ietf.org'" References: <20121015183634.9221.52444.idtracker@ietfa.amsl.com> In-Reply-To: <20121015183634.9221.52444.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.5 X-Forwarded-Message-Id: <20121015183634.9221.52444.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [OPSEC] New IETF I-D about VPN traffic leakages (Fwd: New Version Notification for draft-gont-opsec-vpn-leakages-00.txt) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 18:52:01 -0000 Hi, folks, We have published a new IETF I-D that discusses the VPN traffic-leakage issues that was briefly discussed on this mailing-list a few weeks ago. The I-D is available at: Any feedback will be really welcome. Thanks! Best regards, Fernando -------- Original Message -------- Subject: New Version Notification for draft-gont-opsec-vpn-leakages-00.txt Date: Mon, 15 Oct 2012 11:36:34 -0700 From: internet-drafts@ietf.org To: fgont@si6networks.com A new version of I-D, draft-gont-opsec-vpn-leakages-00.txt has been successfully submitted by Fernando Gont and posted to the IETF repository. Filename: draft-gont-opsec-vpn-leakages Revision: 00 Title: Virtual Private Network (VPN) traffic leakages in dual-stack hosts/ networks Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-gont-opsec-vpn-leakages-00.txt Status: http://datatracker.ietf.org/doc/draft-gont-opsec-vpn-leakages Htmlized: http://tools.ietf.org/html/draft-gont-opsec-vpn-leakages-00 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 a VPN connection may leak out of such connection and be transferred in the clear on the local network. This document discusses some scenarios in which such VPN leakages may occur, either as a side effect of enabling IPv6 on a local network, or as a result of a deliberate attack from a local attacker. Additionally, it discusses possible mitigations for the aforementioned issue. The IETF Secretariat From jouni.nospam@gmail.com Mon Oct 15 13:02:52 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855A921F89B9 for ; Mon, 15 Oct 2012 13:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.585 X-Spam-Level: X-Spam-Status: No, score=-3.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51Sih+dp2JfB for ; Mon, 15 Oct 2012 13:02:52 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A69F921F89BA for ; Mon, 15 Oct 2012 13:02:51 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so3207904wgb.13 for ; Mon, 15 Oct 2012 13:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=+D6PBTe3E2EeoPv8xYAIDPk5ewqjk+he/OMi+h3zDms=; b=YTV7HU+LZmULXw2fPW9tUZiXhhuFtRENBsGRogR48Cv8C6at+zujomOEo7wK6QEhSa nlBuBTitcam/1iwoELT0VVNPRAh8JSe1i2QQnKdAYUgDf3TYYrmpZ3e1Gxe+OjQxS9s8 TiVmoj2rTFr/XAQQeAdPPNSlHE8oM/Up8uXymfgK+GCtRSOlx3/LNz9afP4duu0yicdg 6O2gE5HBtPa1N+TyrsdovoovGM7paTMUsOmln4TFiBRJDToOgQ2Nsctc3E3i6KJ4ZNW5 0jIRy3Jp0EQ8e5Pn3mwab4qCcdaPaxV7Fdhgvl/iSqEfaWukE2qCJeqNblOpSlABMJVt fJXA== Received: by 10.180.99.194 with SMTP id es2mr26142915wib.15.1350331370659; Mon, 15 Oct 2012 13:02:50 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id eq2sm17604004wib.1.2012.10.15.13.02.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Oct 2012 13:02:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Mon, 15 Oct 2012 23:02:39 +0300 Content-Transfer-Encoding: 7bit Message-Id: <3C819693-9F23-4DBF-B5A0-452B5A059D05@gmail.com> References: <20120921170458.23709.58282.idtracker@ietfa.amsl.com> <507036EB.5030409@gmail.com> <50705483.7050209@si6networks.com> <50715688.7000500@si6networks.com> <68379C01-092B-47C7-A0BE-3E5AF36B2230@arbor.net> <50715AE6.9090004@si6networks.com> To: opsec wg mailing list X-Mailer: Apple Mail (2.1084) Cc: draft-ietf-opsec-v6@tools.ietf.org Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-00.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 20:02:52 -0000 Hi, Two quick comments on Section 4.3 Lawful Intercept: In contrast, in mobile environments, since the 3GPP specifications allocate a /64 per device, it may be sufficient to intercept traffic from the /64 rather than specific /128's (since each time the device powers up it gets a new IID). This is not entirely true anymore.. since Release-10 (don't hold your breath when it gets deployed) a device may be delegated a shorter prefix than /64. Also a cellular device may open multiple PDP Context/PDN Connections thus a device may have multiple prefixes, not just one /64. Second, the IID assertion is not correct either. A 3GPP device may use as many IIDs during the lifetime of its PDP Context/PDN Connection as it wishes for its non link-local addresses. Also, depending on the GGSN/PGW implementation, the IID may never change for link-local addresses and can be the same for all devices connected to it (some cellular hosts use that IID also for their non link-local addresses). - Jouni From internet-drafts@ietf.org Wed Oct 17 10:53:34 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808FD21F850B; Wed, 17 Oct 2012 10:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+wrjj7Ob6pm; Wed, 17 Oct 2012 10:53:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083F721F8499; Wed, 17 Oct 2012 10:53:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121017175334.13252.91989.idtracker@ietfa.amsl.com> Date: Wed, 17 Oct 2012 10:53:34 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-efforts-19.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 17:53:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : Security Best Practices Efforts and Documents Author(s) : Chris Lonvick David Spak Filename : draft-ietf-opsec-efforts-19.txt Pages : 41 Date : 2012-10-17 Abstract: This document provides a snapshot of the current efforts to define or apply security requirements in various Standards Developing Organizations (SDO). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-efforts There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-efforts-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-efforts-19 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kkumar@google.com Fri Oct 19 09:51:53 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8950A21F8A78 for ; Fri, 19 Oct 2012 09:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.76 X-Spam-Level: X-Spam-Status: No, score=-102.76 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiItMO-0hNzk for ; Fri, 19 Oct 2012 09:51:50 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3B521F883E for ; Fri, 19 Oct 2012 09:51:49 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so256817qab.10 for ; Fri, 19 Oct 2012 09:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=S0fkAZ67535Z6OlYS7obYhnmKBcG6/c8ja7D//hof7I=; b=l3P1w20g8qQq9EUUEfQO4Yu7jk0ShoJOYJu+SFiyjr01HF0CtYDaE09Ok8X39Cs7o8 AU7NCIiCpJthEPYrpv8KHPDdexG02WBifMKt4S4+dUqHjuu8HJpDEwwR0IEhfkckX9fG vQp+jGgVTEtlJdTr92AnaifD/yh6eI7h7IGv3Zu3wcoW5EKWnS4mxDHa4MQT0YN/RBqg fHTrNfA4RYATgv/Uw/n53TN5yo56zGK2h9DIo4QdblwvWG9QBTby2ndSihGknOxSJOvE ov72D+1yEfADK2PqTIhSgWvDRCEwnXdAVw0SVAOqkRCJy0AH8Cy+BY0p4oV7HZ6mcOy2 1n0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=S0fkAZ67535Z6OlYS7obYhnmKBcG6/c8ja7D//hof7I=; b=XB+9fwcnsbUjSkz1xT5DVHCMpZjpKWQyKUtQNsWkM8by9fLfIwwr2B1CDx3qB2KY3r FGyTXhtYo2jhw0bvtTf7+tP8nR6vjBe2hP4vfpKrvYb7wg4K9+kUofxs77r9/P5LqHaJ UCOtSAz0cU99V0yTK8iV2kdN99I8kC47R5KO/nRvc0yNvMeWnHVwmV536LV5PnU+9Nio p+xBd9J83layDmbQvY8EWwYdOtAywLfn8eG8b21op5HPNqUvTd40sTy3Llq6bKPmJSRI 1tFsTG1JlBoY2dr5z6XVu5I0sDxw5eG+ZsdNiMq+3FXbzl/ohSiVpkZvVkzUYWk4clD5 MZhA== Received: by 10.49.74.99 with SMTP id s3mr1061004qev.0.1350665508854; Fri, 19 Oct 2012 09:51:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.29.104 with HTTP; Fri, 19 Oct 2012 09:51:28 -0700 (PDT) In-Reply-To: References: From: KK Date: Fri, 19 Oct 2012 09:51:28 -0700 Message-ID: To: opsec@ietf.org Content-Type: multipart/alternative; boundary=047d7bd7574add9d5804cc6c5171 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnAyW9nPhdpZRlSzPEvZ5Vpto9pZOnQWQpkZIKypL+XBXTIC7wvlk1k2H/WQ4BLKCIqrVer2WNJG7LzdDsOjBpX0pHzJjiIv3BsENCG0K6y0/MKkQ8CHFPzykmhUT4BGit74BkgUTfa3VJYauIJ3khQtNZASnDqY/NOWPivL4VEn0LIHmeLxZmgToHQXRKiEgwpgCzg Subject: Re: [OPSEC] OPSEC IETF85 Call for Agenda Items X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 16:51:53 -0000 --047d7bd7574add9d5804cc6c5171 Content-Type: text/plain; charset=ISO-8859-1 Dear All, Just a reminder - Please send in your agenda items to us by 22 October 2012. Also, please note - 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 24:00 Thanks, KK, Gunter, Warren On Sun, Oct 14, 2012 at 3:44 PM, KK wrote: > Dear All, > > If you have a draft you would like to discuss during IETF85, please send > your request for agenda time to the opsec chairs. Please include in the > request, the title and file name of the draft, the speakers name, and how > much time you would need. > > We will prioritize drafts that are WG items, drafts that have been > actively discussed on the list, and other individual submissions in that > order. > > Please send in your agenda items to us by 22 October 2012. A few important > dates to note for document submission: > > 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00) > submission by UTC 24:00 > 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 24:00 > > Regards, > KK, Gunter, Warren > > --047d7bd7574add9d5804cc6c5171 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear All,

Just a reminder - Please send in your agenda i= tems to us by 22 October 2012.

Also, please note -= =A02012-10-22 (= Monday): Internet Draft final submission cut-off by UTC 24:00

Thanks,
KK, Gunter, Warren



= On Sun, Oct 14, 2012 at 3:44 PM, KK <kk@google.com> wrote:
Dear All,

If you have a draft you would like = to discuss during IETF85, please send your request for agenda time to the o= psec chairs. Please include in the request, the title and file name of the = draft, the speakers name, and how much time you would need.

We will prioritize drafts that are WG items, drafts tha= t have been actively discussed on the list, and other individual submission= s in that order.

Please send in your agenda items = to us by 22 October 2012. A few important dates to note for document submis= sion:

=A0 2012-10-15 (Monday): Internet Draft Cut-off for ini= tial document (-00) submission by UTC 24:00
=A0 2012-10-22 (Monda= y): Internet Draft final submission cut-off by UTC 24:00

Regards,
KK, Gunter, Warren


--047d7bd7574add9d5804cc6c5171-- From kkumar@google.com Sun Oct 21 12:30:37 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33AFA21F8448 for ; Sun, 21 Oct 2012 12:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.769 X-Spam-Level: X-Spam-Status: No, score=-102.769 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9dDzAFQpv5D for ; Sun, 21 Oct 2012 12:30:36 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8C5E21F8928 for ; Sun, 21 Oct 2012 12:30:35 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1455630lbo.31 for ; Sun, 21 Oct 2012 12:30:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=uHQHa4riyqXwX+pcrtLrduABjshLuwYjEz+QI/uwTDc=; b=Ct+t1ZlxCpjahydgwNFpHEQm0DKB2YqWjv2+iHwwy73722QKWEEPuT55hFgiXAt7Tl 24LPTVbg/7iP80Z1usSM7HGGZc+gat5ExpNkl4XpXD99u9m29FF1hXyy4C9urmdfmkHX 0UeUCw6TjXUO+OmNrvz3kjA0C5LZBxmDAxTZY4ULa4U0rS/qrDHb3GILgC902I7r2hbt pJvz/ol9pG6XrO3zYHFmjj2VfPxcjE1lh/kTWA87vu6pviILyvKpyFXh+H3zxNnxysJS IwicQNgM5DYvKlZ1KaXj6bO3xjc4t22lrkY5sF++TlR+WbxrHBg8Qq0CrKl0d6Cc8B4n TtAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=uHQHa4riyqXwX+pcrtLrduABjshLuwYjEz+QI/uwTDc=; b=Djs1WYuJ134jG4UjItADw2Es+Wja/7TPCo1ac8QtRoY4JNJWteL4sInjquZG1Sx15p 0ED4Hu7i8CDt0GUxgodX7lO8s9NJWyXSujtwQV69PLqdj1rCX6RSXfkO8NSykfCke7EV 5umaDtNpBAX8Dnu+b4y5J6x9IpDg29hSrz/EpJ/rkQ8h+c503qz/f06BTrqvn5V2Ts42 drXi23lsPsLgBTyOCTV0dV+Fdj1yJm4Rt/zo4dC7eRZATCkjJnBptUoU7bBz5e3wwVgS oLvCZ+T999cjfFHIY2VeYKFrotsnJM5y/+cI+uzTfZ/JBg5Kj+SIJ9Gr79TXRNRSLhaR gKwA== Received: by 10.152.105.174 with SMTP id gn14mr6253585lab.55.1350847834570; Sun, 21 Oct 2012 12:30:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.102.201 with HTTP; Sun, 21 Oct 2012 12:30:14 -0700 (PDT) In-Reply-To: <507C5B45.6080500@si6networks.com> References: <20121015183634.9221.52444.idtracker@ietfa.amsl.com> <507C5B45.6080500@si6networks.com> From: KK Date: Sun, 21 Oct 2012 12:30:14 -0700 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=f46d040714c953410a04cc96c531 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmNyG/s2TDOsooF/xm0OKocD8+2jyrcmJBqGsKJz92NmDetpkIUf+DKhZEtxHoMlgVRQBR3imA/LP8ERjdl4bo1bPeNeZnHxv4YPMmg29Fl8WDy7cajB93eB91LPPIAaYTYQ+upRAIZSDNPszjpd1YWxK445h5TfnQ6gW63mWboPchRKa7AEePLchXv0q/Vk9yihawE Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New IETF I-D about VPN traffic leakages (Fwd: New Version Notification for draft-gont-opsec-vpn-leakages-00.txt) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 19:30:37 -0000 --f46d040714c953410a04cc96c531 Content-Type: text/plain; charset=ISO-8859-1 Hey Fernando, Some minor editorial nits and a question... Section 1. "Section 2 provides some background about IPv6 and IPv4 co-existence, summarizing how IPv4 and IPv4 interact on a typical dual-stacked network" I think you meant IPv4 and IPv6 here Section 3. "Therefore, for dual-stacked systems, it is not possible to secure secure the communication with another system without securing both protocols (IPv6 and IPv4)." You repeat secure twice Now for the question: While I understand the premise of the problem here and agree that there is potential for VPN traffic leakages, I am trying to understand the scope of this threat in typical VPN setups. Let's say user Bob wants to access his files from a file server on his enterprise network while enjoying a latte from a cafe. He pulls up his vpn client, establishes a secure connection and tries to connect to filer1.example.com. To me, the use of a VPN client implies that the server is not publicly accessible over the Internet. Now, he gets back an A and AAAA record for filer1.example.com. Typically, that name would resolve to IPvX addresses that are only accessible from within the network. Common security best practices regardless of IPv4 or IPv6 would suggest that you achieve this by either applying appropriate filtering policies to prevent access from the outside world and/or only advertising prefixes that you want global reachability to/from. Let's say that Bob's host prefers the AAAA record and uses IPv6, his request for accessing the files would probably go out in the clear over IPv6 but will most likely end up being dropped either at the local IPv6 router because it has no routes to this protected network, or at the edge of his corporate network by some ACL that blocks access from the outside world. Granted, there is still the potential of one-way communication attempts going out in clear text on Bob's LAN at the cafe and subject to interception. So my question is, is the premise here that the network behind the VPN head end globally routable without any filtering mechanisms in place? If that's the case then yes, VPN leakage here can be severe and detrimental. Thanks, KK On Mon, Oct 15, 2012 at 11:51 AM, Fernando Gont wrote: > Hi, folks, > > > We have published a new IETF I-D that discusses the VPN traffic-leakage > issues that was briefly discussed on this mailing-list a few weeks ago. > > The I-D is available at: > > > Any feedback will be really welcome. > > Thanks! > > Best regards, > Fernando > > --f46d040714c953410a04cc96c531 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Fernando,

Some minor editorial nits and a question..= .

Section 1.

"S= ection 2 provides some background about IPv6 and IPv4 co-existence,=A0summa= rizing how IPv4 and IPv4 interact on a typical dual-stacked=A0network"=

I think you meant IPv4 and IPv6 here
Section 3.=A0

"Therefore, f= or dual-stacked systems, it is not possible to secure secure the=A0communic= ation with another system without securing both protocols=A0(IPv6 and IPv4)= ."

You repeat secure twice

= Now for the question:

While I understand the premi= se of the problem here and agree that there is potential for VPN traffic le= akages, I am trying to understand the scope of this threat in typical VPN s= etups.

Let's say user Bob wants to access his files f= rom a file server on his enterprise network while enjoying a latte from a c= afe. He pulls up his vpn client, establishes a secure connection and tries = to connect to filer= 1.example.com. To me, the use of a VPN client implies that the server i= s not publicly accessible over the Internet.=A0

Now, he gets back an A and AAAA record for filer1.example.com. Typical= ly, that name would resolve to IPvX addresses that are only accessible from= within the network.=A0Common security best practices regardless of IPv4 or= IPv6 would suggest that you achieve this by either applying appropriate fi= ltering policies to prevent access from the outside world and/or only=A0adv= ertising prefixes that you want global reachability to/from.

Let's say that Bob's host prefers the AAAA reco= rd and uses IPv6, his request for accessing the files would probably go out= in the clear over IPv6 but will most likely end up being dropped either at= the local IPv6 router because it has no routes to this protected network, = or at the edge of his corporate network by some ACL that blocks access from= the outside world. Granted, there is still the potential of one-way commun= ication attempts going out in clear text on Bob's LAN at the cafe and s= ubject to interception.

So my question is, is the premise here that the n= etwork behind the VPN head end globally routable without any filtering mech= anisms in place? If that's the case then yes, VPN leakage here can be s= evere and detrimental.=A0

Thanks,
KK


On Mon, Oct 1= 5, 2012 at 11:51 AM, Fernando Gont <fgont@si6networks.com> wrote:
Hi, folks,


We have published a new IETF I-D that discusses the VPN traffic-leakage
issues that was briefly discussed on this mailing-list a few weeks ago.

The I-D is available at:
<http://www.ietf.org/internet-drafts/draft-g= ont-opsec-vpn-leakages-00.txt>

Any feedback will be really welcome.

Thanks!

Best regards,
Fernando

--f46d040714c953410a04cc96c531-- From fgont@si6networks.com Sun Oct 21 22:41:50 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516B521F8B89 for ; Sun, 21 Oct 2012 22:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFdKDPblW+pf for ; Sun, 21 Oct 2012 22:41:49 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0BE21F87E0 for ; Sun, 21 Oct 2012 22:41:46 -0700 (PDT) Received: from [186.134.3.250] (helo=[192.168.123.123]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TQAli-0005Bt-DU; Mon, 22 Oct 2012 07:41:42 +0200 Message-ID: <50848018.1040302@si6networks.com> Date: Sun, 21 Oct 2012 20:07:04 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: KK References: <20121015183634.9221.52444.idtracker@ietfa.amsl.com> <507C5B45.6080500@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New IETF I-D about VPN traffic leakages (Fwd: New Version Notification for draft-gont-opsec-vpn-leakages-00.txt) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 05:41:50 -0000 Hi, KK, Thanks so much for your feedback! -- Please find my comments inline... On 10/21/2012 04:30 PM, KK wrote: > Some minor editorial nits and a question... > > Section 1. > > "Section 2 provides some background about IPv6 and IPv4 > co-existence, summarizing how IPv4 and IPv4 interact on a typical > dual-stacked network" > > I think you meant IPv4 and IPv6 here [....] Yep -- I will fix this and the other reported nits. > Let's say user Bob wants to access his files from a file server on his > enterprise network while enjoying a latte from a cafe. He pulls up his > vpn client, establishes a secure connection and tries to connect to > filer1.example.com . To me, the use of a VPN > client implies that the server is not publicly accessible over the > Internet. Agreed. But the vulnerability being discussed does not really imply that the attacker is able to get access to some resources he'd otherwise not have access to, but rather that there's a traffic leakage. e.g., if the client employs some insecure protocol (e.g., that sends user and password in the clear), he may think it's okay to use it over a VPN. But with this attack, that user/pass could end up appearing in the clear on the local network. Another example: the user might be employing some protocol that does not include confidentiality services (e.g., MSN) -- but the user thinks that's still okay, since he's using that protocol over a VPN. But then the corresponding traffic might be sent on the local network, in the clear. > Now, he gets back an A and AAAA record for filer1.example.com > . Typically, that name would resolve to IPvX > addresses that are only accessible from within the network. Common > security best practices regardless of IPv4 or IPv6 would suggest that > you achieve this by either applying appropriate filtering policies to > prevent access from the outside world and/or only advertising prefixes > that you want global reachability to/from. Agreed. But the I-D is not implying this attack scenario. -- Please do let me know if you think this is not clear, and, in such case, where/how I could improve the I-D. > outside world. Granted, there is still the potential of one-way > communication attempts going out in clear text on Bob's LAN at the cafe > and subject to interception. Exactly. This attack scenario, along with the case in which the client is employing the VPN for having some sort of confidentiality at least on the way out of the insecure network he's connecting to, are the scenarios that this I-D is discussing. > So my question is, is the premise here that the network behind the VPN > head end globally routable without any filtering mechanisms in place? If > that's the case then yes, VPN leakage here can be severe and detrimental. Nope. For instance, the I-D is not supposed to discuss such kind of scenario, but rather the other two attack scenarios I've mentioned above. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From internet-drafts@ietf.org Mon Oct 22 12:03:49 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6850921F8B4D; Mon, 22 Oct 2012 12:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0diA5+j93bk; Mon, 22 Oct 2012 12:03:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8C71F0C44; Mon, 22 Oct 2012 12:03:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022190344.30521.76711.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 12:03:44 -0700 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 19:03:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : Using Only Link-Local Addressing Inside an IPv6 Network Author(s) : Michael Behringer Eric Vyncke Filename : draft-ietf-opsec-lla-only-02.txt Pages : 9 Date : 2012-10-22 Abstract: In an IPv6 network it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to help the decision process for a given network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-lla-only-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-lla-only-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mbehring@cisco.com Mon Oct 22 12:07:13 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB5A21F8A6B for ; Mon, 22 Oct 2012 12:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFcHLSJfNOda for ; Mon, 22 Oct 2012 12:07:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D5F6A21F8A25 for ; Mon, 22 Oct 2012 12:07:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2024; q=dns/txt; s=iport; t=1350932829; x=1352142429; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5cYd5CJIiYUeTZKDIUkxqDvGjZEQFVyA/+Kjy0zM9c8=; b=V7i4WdsW/dByZvjCNesGoQQ+UTLYK37pwjJ2nhMNYP7uwZZMK7aWGm0x CPA8s54s0h5qBzOCPArWS/S6HuZFltAMNOVFLG4Q+Cze+2YIL0yQMwiDM 1A0ap6XANbzOThNIrqo/fvRu2TVS6I+OoHoQEUsudlnaJiBIBqsEQV2Sd o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANmYhVCtJXG//2dsb2JhbABFwSuBCIIgAQEBBAEBAQ8BJzQXBAIBCBEEAQELFAkHJwsUCQgCBBMIARmHYgubfqAEi1+GD2ADlwiNN4Frgm+CGA X-IronPort-AV: E=Sophos;i="4.80,631,1344211200"; d="scan'208";a="134243291" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 22 Oct 2012 19:07:08 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9MJ77v0005749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Oct 2012 19:07:07 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 14:07:07 -0500 From: "Michael Behringer (mbehring)" To: "opsec@ietf.org" Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt Thread-Index: AQHNsIgHWIt7F0oZdkaBLcQRAGH49ZfFr03Q Date: Mon, 22 Oct 2012 19:07:07 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F5703C8@xmb-rcd-x14.cisco.com> References: <20121022190344.30521.76711.idtracker@ietfa.amsl.com> In-Reply-To: <20121022190344.30521.76711.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.194.20] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--38.114800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 19:07:13 -0000 WG chairs,=20 We just submitted a new version of the link-local draft, with a number of s= mall edits, and now also a section on IXPs (follow-up from the interim meet= ing in Amsterdam). If there is still a slot available in Atlanta, we'd lik= e to briefly present and discuss the changes. Thanks, Eric and Michael > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: 22 October 2012 21:04 > To: i-d-announce@ietf.org > Cc: opsec@ietf.org > Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Operational Security Capabilities for I= P > Network Infrastructure Working Group of the IETF. >=20 > Title : Using Only Link-Local Addressing Inside an IPv6 Networ= k > Author(s) : Michael Behringer > Eric Vyncke > Filename : draft-ietf-opsec-lla-only-02.txt > Pages : 9 > Date : 2012-10-22 >=20 > 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. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-opsec-lla-only-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-lla-only-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From kkumar@google.com Mon Oct 22 16:59:59 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14471F0C5C for ; Mon, 22 Oct 2012 16:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.777 X-Spam-Level: X-Spam-Status: No, score=-102.777 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akAK08FgiRhC for ; Mon, 22 Oct 2012 16:59:59 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id AC7D621F89D4 for ; Mon, 22 Oct 2012 16:59:58 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id s14so2201261qcg.31 for ; Mon, 22 Oct 2012 16:59:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=HGbguedCP8fIvT6hlPRooJst17U3UYDk+R10fTHpiJw=; b=Z/hqv/+rSYnKU8o8Ihok5doS9fkkDimXuP+xk+zpKbJqPlQW8wIoVSURJGMSekfIXN h/9Vt44kanMoJC8ICCiP5+SU467dSDErCXAVAvN26GRClJT6IOtFKA8TPvqKfGVHzQwZ 2Dvda6WsSQg/rSkGnSDrvVyFk1FskOa8oxVu9EwOcUtSFKK0+lAtCPwnSvGHdNPY4zJs TvxyF0lNKdw/oVtBOautzspFjtnmG8uHljdNVAv1L6Jcd+4IvbcSwgUes5Ny+vqhw2Lm D5IfIzSMBGPenV5XyA0YnZ/T3uss8eckCWD0A0OZWNoeOfIRIa1gY42ahGzDvPEOZIQ4 63PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=HGbguedCP8fIvT6hlPRooJst17U3UYDk+R10fTHpiJw=; b=eANGM3rSKcCyBSelpsatYti+SSgDIR6pV9V1bwnv96Ti/HgfOuQ+nraocuuTLcamdD D+h0m8v/iHedBvP0b0i8E6Nqg4nursimkGcVIvm35C2C/WmR4uHmvh6lHcI8HHf/YMOV 692C+yoxW5ztsbgttOsuVrpOviEv/g5PDIZA9xXtqZpJa5kuS3YndLpXtZ3/8JKR/nA2 FwfunNDW/HbfvqODWY5jF36fem9wKuKuqSK+AmRX1IjGKvJmaOQFth1VfU2oBCXV8EJc JBRt0s4yUKpK084E8UFCMyfBINfDRrQLsrmgdkNVlM489Br30qctK3grdwNxDhdBgd4o 00SQ== Received: by 10.49.3.234 with SMTP id f10mr5863918qef.45.1350950398019; Mon, 22 Oct 2012 16:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.29.104 with HTTP; Mon, 22 Oct 2012 16:59:37 -0700 (PDT) In-Reply-To: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F5703C8@xmb-rcd-x14.cisco.com> References: <20121022190344.30521.76711.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF0F5703C8@xmb-rcd-x14.cisco.com> From: KK Date: Mon, 22 Oct 2012 16:59:37 -0700 Message-ID: To: "Michael Behringer (mbehring)" Content-Type: multipart/alternative; boundary=047d7bb03e689547b504ccaea655 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk546980mi3YJ4Zvc2UOVlJj3/AXdPmLMWFsL92PLn4JXVrdUDMiE5+cBQjQ9+AefuvCE9NE/pTbPRhP6PnoyVqltKPtjLqmKBQ3BMGzPAf0XiR5vOwely6sisxTffoY9xCu+zow0oKwvMMWwNeN4EJsOalM+LClaJyJDO27Zd/f5T5xLTAkQC4IJC2iPZR2Zr6Roh6 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 23:59:59 -0000 --047d7bb03e689547b504ccaea655 Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, How much time do you think you would need? Thanks, KK On Mon, Oct 22, 2012 at 12:07 PM, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > WG chairs, > > We just submitted a new version of the link-local draft, with a number of > small edits, and now also a section on IXPs (follow-up from the interim > meeting in Amsterdam). If there is still a slot available in Atlanta, we'd > like to briefly present and discuss the changes. > > Thanks, > Eric and Michael > > > > -----Original Message----- > > From: opsec-bounces@ietf.org [mailto:opsec-bounces@ietf.org] On Behalf > > Of internet-drafts@ietf.org > > Sent: 22 October 2012 21:04 > > To: i-d-announce@ietf.org > > Cc: opsec@ietf.org > > Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Operational Security Capabilities for > IP > > Network Infrastructure Working Group of the IETF. > > > > Title : Using Only Link-Local Addressing Inside an IPv6 > Network > > Author(s) : Michael Behringer > > Eric Vyncke > > Filename : draft-ietf-opsec-lla-only-02.txt > > Pages : 9 > > Date : 2012-10-22 > > > > Abstract: > > In an IPv6 network it is possible to use only link-local addresses on > > infrastructure links between routers. This document discusses the > > advantages and disadvantages of this approach to help the decision > > process for a given network. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-opsec-lla-only-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-lla-only-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 > --047d7bb03e689547b504ccaea655 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael,

How much time do you think you would need?

Thanks,
KK


On Mon, Oct 22, 2012 at 12:07 PM, Mich= ael Behringer (mbehring) <mbehring@cisco.com> wrote:
WG chairs,

We just submitted a new version of the link-local draft, with a number of s= mall edits, and now also a section on IXPs (follow-up from the interim meet= ing in Amsterdam). =A0If there is still a slot available in Atlanta, we'= ;d like to briefly present and discuss the changes.

Thanks,
Eric and Michael


> -----Original Message-----
> From: opsec-bounces@ietf.org= [mailto:opsec-bounces@ietf.o= rg] On Behalf
> Of internet-drafts@ietf.or= g
> Sent: 22 October 2012 21:04
> To: i-d-announce@ietf.org=
> Cc: opsec@ietf.org
> Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> =A0This draft is a work item of the Operational Security Capabilities = for IP
> Network Infrastructure Working Group of the IETF.
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Using Only Link-Local Addressi= ng Inside an IPv6 Network
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Michael Behringer
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Eric Vyncke
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-opsec-lla-only-02.txt=
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 9
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-10-22
>
> Abstract:
> =A0 =A0In an IPv6 network it is possible to use only link-local addres= ses on
> =A0 =A0infrastructure links between routers. =A0This document discusse= s the
> =A0 =A0advantages and disadvantages of this approach to help the decis= ion
> =A0 =A0process for a given network.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-on= ly
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-opsec-lla-only-02=
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec= -lla-only-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec

--047d7bb03e689547b504ccaea655-- From fernando@gont.com.ar Mon Oct 22 19:46:00 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B4F1F0429; Mon, 22 Oct 2012 19:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+VWE5hEUY04; Mon, 22 Oct 2012 19:45:59 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id 98F7B21F843B; Mon, 22 Oct 2012 19:45:59 -0700 (PDT) Received: from [186.134.30.80] (helo=[192.168.123.120]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TQUV8-00073w-MH; Tue, 23 Oct 2012 04:45:55 +0200 Message-ID: <5085F644.5030206@gont.com.ar> Date: Mon, 22 Oct 2012 22:43:32 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" References: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> In-Reply-To: <67832B1175062E48926BF3CB27C49B2408182EDE@xmb-aln-x12.cisco.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "v6ops v6ops WG \(v6ops@ietf.org\)" , "opsec@ietf.org" Subject: Re: [OPSEC] [v6ops] Passive IP addresses - 2th iteration X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 02:46:00 -0000 Folks, [Disclaimer: I'm catching up with email, and may ahve missed important discussions] On 10/07/2012 06:29 AM, Gunter Van de Velde (gvandeve) wrote: > Q) what does the passive keyword result into > > A) If the recipient device receives an IP packet with this passive > address in the destination address and is destined for this device, then > the packet will be dropped. However, when the device gets for example a > packet with TTL expired (for trace-route) then this passive address > could be used as the source address Is this any different from an IPv6 "alias" + the corresponding ACLs? Cheers, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From liushucheng@huawei.com Mon Oct 22 20:57:56 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08D831F0C8A for ; Mon, 22 Oct 2012 20:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C19LBFmUtD5v for ; Mon, 22 Oct 2012 20:57:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1819E1F0C86 for ; Mon, 22 Oct 2012 20:57:54 -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.5-GA FastPath queued) with ESMTP id ALX45067; Tue, 23 Oct 2012 03:57:54 +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.1.323.3; Tue, 23 Oct 2012 04:57:46 +0100 Received: from SZXEML427-HUB.china.huawei.com (10.72.61.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 23 Oct 2012 04:57:51 +0100 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.157]) by szxeml427-hub.china.huawei.com ([10.72.61.35]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 11:57:48 +0800 From: "Will Liu (Shucheng)" To: "opsec@ietf.org" Thread-Topic: New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-02.txt Thread-Index: AQHNsGOg1TUH9F/X2026rZRbHDKz6pfGQt/ggAABQ0A= Date: Tue, 23 Oct 2012 03:57:47 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.79.130] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [OPSEC] FW: New Version Notification for draft-zhang-ipsecme-multi-path-ipsec-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 03:57:56 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIG1vZGlmaWVkIG91ciBtdWx0aXBhdGggaXBzZWMgZHJhZnQgYWNj b3JkaW5nIHRvIHNvbWUgb2YgdGhlIGNvbW1lbnRzIGZyb20gdGhlIG1haWwgbGlzdDoNCg0KLSBB ZGRlZCBhIHNlY3Rpb24gdG8gZGlzY3VzcyB0aGUgcmVvcmRlciBpc3N1ZS4NCi0gQ29tcGFyZWQg d2l0aCBTQSwgaW5zdGVhZCBvZiBTQSBidW5kbGUuDQoNCllvdXIgcmV2aWV3IGFuZCBjb21tZW50 cyBhcmUgaGlnaGx5IGFwcHJlY2lhdGVkLiANCg0KV2lsbA0KDQpSZWdhcmRzLA0KU2h1Y2hlbmcg TElVIChXaWxsKQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2Vu dDogTW9uZGF5LCBPY3RvYmVyIDIyLCAyMDEyIDEwOjQ0IFBNDQpUbzogV2lsbCBMaXUgKFNodWNo ZW5nKQ0KQ2M6IFRpbmEgVFNPVTsgdnpoYW5nMjAwOEB5YWhvby5jb20NClN1YmplY3Q6IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtemhhbmctaXBzZWNtZS1tdWx0aS1wYXRoLWlw c2VjLTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC16aGFuZy1pcHNlY21l LW11bHRpLXBhdGgtaXBzZWMtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFdpbGwgTGl1IGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVu YW1lOgkgZHJhZnQtemhhbmctaXBzZWNtZS1tdWx0aS1wYXRoLWlwc2VjDQpSZXZpc2lvbjoJIDAy DQpUaXRsZToJCSBNdWx0aXBsZSBQYXRoIElQIFNlY3VyaXR5DQpDcmVhdGlvbiBkYXRlOgkgMjAx Mi0xMC0yMg0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6 IDgNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtemhhbmctaXBzZWNtZS1tdWx0aS1wYXRoLWlwc2VjLTAyLnR4dA0KU3RhdHVzOiAgICAg ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLWlwc2VjbWUt bXVsdGktcGF0aC1pcHNlYw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC16aGFuZy1pcHNlY21lLW11bHRpLXBhdGgtaXBzZWMtMDINCkRpZmY6ICAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtemhhbmctaXBzZWNt ZS1tdWx0aS1wYXRoLWlwc2VjLTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBwcmVz ZW50cyBvbmUgYXBwcm9hY2ggdG8gZW5oYW5jZSBkYXRhIHByb3RlY3Rpb24gd2hlbg0KICAgdHJh bnNtaXR0aW5nIElQc2VjIGRhdGFncmFtcyBhY3Jvc3MgdGhlIGluc2VjdXJlIG5ldHdvcmtzLiAg VGhlDQogICBtZXRob2QgYWZmb3JkcyB0aGUgc3Ryb25nZXIgcHJvdGVjdGlvbiB0byB0aGUgdHJh ZmZpYyBieSBzcGxpdHRpbmcgaXQNCiAgIGFtb25nIGEgc2V0IG9mIHN1Yi10dW5uZWxzLiAgQWxs IHRoZSBTZWN1cml0eSBBc3NvY2lhdGlvbnMgKFNBcykgYXJlDQogICBzZXQgdXAgaW5kZXBlbmRl bnRseSBmb3IgYWxsIHN1Yi10dW5uZWxzLiAgQm90aCB0aGUgc2VuZGluZyBhbmQNCiAgIHJlY2Vp dmluZyBlbnRpdHkgY29tYmluZSBhbGwgdGhlIHN1Yi10dW5uZWxzIHRvIG9uZSBjbHVzdGVyZWQg dHVubmVsLg0KICAgQXMgZGlmZmVyZW50IHN1Yi10dW5uZWwgdXNlcyBkaWZmZXJlbnQgY3J5cHRv IGtleSBtYXRlcmlhbHMgYW5kDQogICBwcm9jZXNzaW5nIHBhcmFtZXRlcnMsIGl0IG1heSBhY2hp ZXZlIHRoZSBzdHJvbmdlciBwcm90ZWN0aW9uIG9mIHRoZQ0KICAgdHJhZmZpYyBhY3Jvc3MgdGhl IGluc2VjdXJlIG5ldHdvcmtzLiAgSW4gYWRkaXRpb24sIGl0IGNvdWxkIHBvc3NpYmx5DQogICBi cmluZyBtb3JlIGJlbmVmaXRzIGluIHRlcm1zIG9mIHRoZSBuZXR3b3JrIGNvbnRyb2wuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From mbehring@cisco.com Tue Oct 23 00:26:21 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250EB21F8440 for ; Tue, 23 Oct 2012 00:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj5DfG8JOd7X for ; Tue, 23 Oct 2012 00:26:20 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 5958E21F8444 for ; Tue, 23 Oct 2012 00:26:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11288; q=dns/txt; s=iport; t=1350977180; x=1352186780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3IDv84srpSEAFvIi30VdVq4vkBvJEfkqNWRbl/REPcI=; b=PKj+Kq0PCd95I1Vsj90dhqg61MeYC1pae+HpN+GIEbd3udBg81r2T/as TcH4uSEEeoQ9x/IYdQS75iCJ2Lgau+rqDoNALHK/Pve9ljJIXnE+yBowC PHmkWwxsBVXGt94AJOH3Th/ziakGPTftITTdpsR2geNg5Xc/ZpXGtlBN+ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAE1FhlCtJV2Y/2dsb2JhbABEgkq2MAGIZ4EIgiABAQEEAQEBDwEaQQsMBAIBCBEEAQELHQcnCxQJCAIEDgUIARmHYgucNo9ckE2LWIYPYAOXCI03gWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,633,1344211200"; d="scan'208,217";a="134401594" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 23 Oct 2012 07:26:18 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9N7QHEd004607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 07:26:17 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.51]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 02:26:17 -0500 From: "Michael Behringer (mbehring)" To: KK Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt Thread-Index: AQHNsIgHWIt7F0oZdkaBLcQRAGH49ZfFr03QgACmCYCAACix4A== Date: Tue, 23 Oct 2012 07:26:16 +0000 Message-ID: <3AA7118E69D7CD4BA3ECD5716BAF28DF0F5708FA@xmb-rcd-x14.cisco.com> References: <20121022190344.30521.76711.idtracker@ietfa.amsl.com> <3AA7118E69D7CD4BA3ECD5716BAF28DF0F5703C8@xmb-rcd-x14.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.194.20] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--45.404800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_3AA7118E69D7CD4BA3ECD5716BAF28DF0F5708FAxmbrcdx14ciscoc_" MIME-Version: 1.0 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 07:26:21 -0000 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF0F5708FAxmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi KK, 10-15 min would be great! Thanks, Michael From: KK [mailto:kk@google.com] Sent: 23 October 2012 02:00 To: Michael Behringer (mbehring) Cc: opsec@ietf.org Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt Hi Michael, How much time do you think you would need? Thanks, KK On Mon, Oct 22, 2012 at 12:07 PM, Michael Behringer (mbehring) > wrote: WG chairs, We just submitted a new version of the link-local draft, with a number of s= mall edits, and now also a section on IXPs (follow-up from the interim meet= ing in Amsterdam). If there is still a slot available in Atlanta, we'd lik= e to briefly present and discuss the changes. Thanks, Eric and Michael > -----Original Message----- > From: opsec-bounces@ietf.org [mailto:opsec= -bounces@ietf.org] On Behalf > Of internet-drafts@ietf.org > Sent: 22 October 2012 21:04 > To: i-d-announce@ietf.org > Cc: opsec@ietf.org > Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Operational Security Capabilities for I= P > Network Infrastructure Working Group of the IETF. > > Title : Using Only Link-Local Addressing Inside an IPv6 N= etwork > Author(s) : Michael Behringer > Eric Vyncke > Filename : draft-ietf-opsec-lla-only-02.txt > Pages : 9 > Date : 2012-10-22 > > Abstract: > In an IPv6 network it is possible to use only link-local addresses on > infrastructure links between routers. This document discusses the > advantages and disadvantages of this approach to help the decision > process for a given network. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-opsec-lla-only-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-lla-only-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 --_000_3AA7118E69D7CD4BA3ECD5716BAF28DF0F5708FAxmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi KK,

 <= /p>

10-15 min would be great!

 <= /p>

Thanks,

Michael=

 <= /p>

From: KK [mailto:kk@google.com]
Sent: 23 October 2012 02:00
To: Michael Behringer (mbehring)
Cc: opsec@ietf.org
Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt

 

Hi Michael,

 

How much time do you think you would need?

 

Thanks,

KK

 

On Mon, Oct 22, 2012 at 12:07 PM, Michael Behringer = (mbehring) <mbeh= ring@cisco.com> wrote:

WG chairs,

We just submitted a new version of the link-local draft, with a number of s= mall edits, and now also a section on IXPs (follow-up from the interim meet= ing in Amsterdam).  If there is still a slot available in Atlanta, we'= d like to briefly present and discuss the changes.

Thanks,
Eric and Michael



> -----Original Message-----
> From: opsec-bounces@ietf.org= [mailto:opsec-bounces@ietf.o= rg] On Behalf
> Of internet-drafts@ietf.or= g
> Sent: 22 October 2012 21:04
> To: i-d-announce@ietf.org=
> Cc: opsec@ietf.org
> Subject: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-02.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Operational Security Capabiliti= es for IP
> Network Infrastructure Working Group of the IETF.
>
>       Title           : Using = Only Link-Local Addressing Inside an IPv6 Network
>       Author(s)       : Michael Behringe= r
>                     =       Eric Vyncke
>       Filename        : draft-ietf-= opsec-lla-only-02.txt
>       Pages           : 9
>       Date            : 2= 012-10-22
>
> Abstract:
>    In an IPv6 network it is possible to use only link-local = addresses on
>    infrastructure links between routers.  This document= discusses the
>    advantages and disadvantages of this approach to help the= decision
>    process for a given network.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-opsec-lla-only
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-opsec-lla-only-02
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-lla-only-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OPSEC mailing list
> OPSEC@ietf.org
> https://www.ietf.org/mailman/listinfo/opsec
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec

 

--_000_3AA7118E69D7CD4BA3ECD5716BAF28DF0F5708FAxmbrcdx14ciscoc_-- From kkumar@google.com Wed Oct 24 14:11:35 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCCE21F8B88 for ; Wed, 24 Oct 2012 14:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.785 X-Spam-Level: X-Spam-Status: No, score=-102.785 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4b82et9vAKc for ; Wed, 24 Oct 2012 14:11:35 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D20F021F8B6C for ; Wed, 24 Oct 2012 14:11:34 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id 25so3024857qao.10 for ; Wed, 24 Oct 2012 14:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record; bh=EOMVF/epbWcO8lHjiy9LwlL18Q1P8lpx8FJcVcy3ld0=; b=HvcMKuo9wF7mM+XHwIkSoJocODCHPA5Cvy7BS2CAO7UI1iLPLBz/rRgseCUaq76JNK rQpo8m0yGMVAh5tJc+JkTWarGr+yn/3HBOq/3b8NrZbEb+wHJf3ikcGdlMzbePVDgILg hdYw+pGZN9AYih1bggro/yxxZgtgZ21qQoONS5abhm226BB6CQgwyrC2hgxdPAZO6eya Mv8lu9hOTIfjzseGQLGE1bmifbBy9jhQYo9u6Mt/fkQRjco66aa/MYVOwl+wcCH3xQUQ wcKMc3p5F54hd6lFFqPmAVaKk6BuKcQoXVqFnOccLbAX9c+AapQu0PJ5eJPvId5SBlM5 f0Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=EOMVF/epbWcO8lHjiy9LwlL18Q1P8lpx8FJcVcy3ld0=; b=Cti+PsIH5H0EAullw3LAKITP+lDoFrjEtZGwNi5bHcFiVN425sIi7eCXh2yOBGUM2Q VPI9CrRXMMrj3PcwkbuocnAucKlVSOuALvLi6VB9jpI1csavKsp6P2iRwxi+4PAlh+hL QV2TmenvHZicdRijdy2fpVV+Vc3KUYJA9Kglbo23hrtx0KHR3M+NojFKDAkCHzbjbmaT dkUugnERruU8XCyHV/MAcRSf3Iuz+boew32vcA+vD8rklrB5329bvFhpoBqZM7TDscdR M5OOElKyp5V5esfqJm5LWL6nfn69sVGzkk/AY0ab1olT8o9/ib5xIGng7qcXEfxf2SxT 7Hkw== Received: by 10.49.60.72 with SMTP id f8mr9631499qer.30.1351113094213; Wed, 24 Oct 2012 14:11:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.29.104 with HTTP; Wed, 24 Oct 2012 14:11:14 -0700 (PDT) From: KK Date: Wed, 24 Oct 2012 14:11:14 -0700 Message-ID: To: "opsec@ietf.org" Content-Type: multipart/alternative; boundary=047d7b6da4c4082e5404ccd488b9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnZ5/Y2m8PFUYkZg/j16wp9rzzxyM81p//EfElwSiZSIdMBF339PkrUusH3C6uMBGsFvt/3eSs+x59vaEjfJN7o01bWTmpDhePxy9E/8vFKujJ78ttFHVUYpFLPHHG2uzeetepY7+v5UI3eMincgADiX+6GyI5Qx9TuunNqbUxEYL51NlGB6T84SW/G9YQKLsIXel4E Cc: "opsec-chairs@ietf.org" Subject: [OPSEC] Draft Agenda for OPSEC @IETF85 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 21:11:35 -0000 --047d7b6da4c4082e5404ccd488b9 Content-Type: text/plain; charset=ISO-8859-1 Hey Folks, A draft agenda has been posted here . """ *Operational Security Capabilities for IP Network Infrastructure - IETF 85 Friday, Nov 9, 0900 - 1100 Room: Salon C ----------------------- Administrivia, Agenda Bashing, 10 Minutes Using Only Link-Local Addressing Inside an IPv6 Network draft-ietf-opsec-lla-only, 15 Minutes Operational Security Considerations for IPv6 Networks draft-ietf-opsec-v6, 15 minutes BGP Operations and Security draft-jdurand-bgp-security, 20 Minutes Network Reconnaissance in IPv6 Networks draft-gont-opsec-ipv6-host-scanning, 15 Minutes DHCPv6-Shield: Protecting Against Rogue DHCPv6 Servers draft-gont-opsec-dhcpv6-shield, 10 Minutes Virtual Private Network (VPN) traffic leakages in dual-stack hosts/networks draft-gont-opsec-vpn-leakages, 15 Minutes Passive IP addresses draft-baker-opsec-passive-ip-address, 15 minutes """* * Regards,* *KK, Gunter, Warren * --047d7b6da4c4082e5404ccd488b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey Folks,

A draft agenda has been posted h= ere.=A0

"""

Operational Security Cap= abilities for IP Network Infrastructure - IETF 85
=A0=A0=A0=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0= =A0=A0=A0Friday, Nov 9, 0900 - 1100
=A0=A0=A0= =A0=A0=A0=A0=A0Room: Salon C
=A0=A0=A0=A0=A0=A0=A0=A0=A0-----------------------
=A0=A0=A0=A0=A0=A0= =A0=A0=A0Administrivia, Agenda Bashing, 10 Minutes
=A0=A0=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0= =A0=A0=A0=A0Using Only Link-Local Addressing Inside an IPv6 Network
=A0=A0=A0=A0=A0=A0=A0=A0=A0draft-ietf-opsec-= lla-only, 15 Minutes

=A0=A0=A0=A0=A0=A0=A0=A0O= perational Security Considerations for IPv6 Networks
=A0=A0=A0=A0=A0=A0=A0=A0draft-ietf-opsec-v6, 15 minutes

=A0=A0=A0=A0=A0=A0=A0=A0B= GP Operations and Security
=A0=A0=A0=A0=A0=A0=A0=A0draft-jdurand-bgp-security, 20 Minutes

=A0=A0=A0=A0=A0=A0=A0=A0N= etwork Reconnaissance in IPv6 Networks
=A0=A0=A0=A0=A0=A0=A0=A0draft-gont-opsec-ipv6-host-scanning= , 15 Minutes

=A0=A0=A0=A0=A0=A0=A0=A0D= HCPv6-Shield: Protecting Against Rogue DHCPv6 Servers
=A0=A0=A0=A0=A0=A0=A0=A0draft-gont-opsec-dhcpv6-shield, 10 Minut= es

=A0=A0=A0=A0=A0=A0=A0=A0V= irtual Private Network (VPN) traffic leakages in dual-stack hosts/networks<= /span>
=A0=A0=A0=A0=A0=A0=A0=A0draft-gont-opsec-vpn-leakages, 15 Minutes=

=A0= =A0=A0=A0=A0=A0=A0=A0Passive IP addresses
=A0=A0=A0=A0=A0=A0=A0=A0draft-baker-opsec-passive-ip-address<= /a>, 15 minutes

"""
KK, Gunter, Warren


--047d7b6da4c4082e5404ccd488b9-- From kkumar@google.com Fri Oct 26 14:43:45 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EF721F867E for ; Fri, 26 Oct 2012 14:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iB9m+Nz+-x0 for ; Fri, 26 Oct 2012 14:43:44 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2468921F8689 for ; Fri, 26 Oct 2012 14:43:43 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2982296lam.31 for ; Fri, 26 Oct 2012 14:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=9q0hjVyhtxmSOm2Lu9RQWbuzCrBWqQwJf1dW/UeNsHE=; b=Gld3ZJ93NmXJRL7reOG/jK0njpU3aysWmKL0GfOuVLAyqhbXW9+66+qGYoXUrFOMWg g4dyj+47s0A/AzSic6ikCe5ljW/D+WT5leFqHsC/PW54EkY0zb794yaSgfLSXfmqQ8AW MI0DV6hVL3cSJ5FCH0/Q6gVqOKqfaq8umoVDJx9PZY4LiU0qANCQjumXbcJ1TaG/XIed Rk5z2x+VjEJ4noWNnkhp/Z1546RKyVhYPjue58HFlOwQzB+WiH5wV0xvklMeTrXuQ8Fk D0N3AH2GUTSf7PutvTqlElr60Zu5fscgxejUPIGWPCZ2sLK6X0PiB8oO4OCRPG6Zhfu7 iMHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=9q0hjVyhtxmSOm2Lu9RQWbuzCrBWqQwJf1dW/UeNsHE=; b=EkW2rdQDv6r1KuUJrlmJpoMPhtznFgssI0WeAQDO+EoFxMLpXY/imjmuj87ndlJMO/ 58taezbpHvPQIYKyYgFe7JgMrekuqM2x2P+9FPGdjZ6h7NxCr8HIZBZ9l5mR8cu/wsEo PZAftZZZzSqz2ca0B8L2+qDhv7QpFiYl3yy2Vx93GjkLCUZa8WgTsF65GykLYyEplG+o epvBKwS2TkYlJgOND5QTyXRl7oh9/2ounKPYD3dCIEAwX/eFY7ld1P3WxChzyEi9P5Se 22FVrJle7BGbvuRB+n5tiw99bxZJl7CWX9CXGZ7Emw2e6nFKITv7tzXw7qUiDKepBDAV r86A== Received: by 10.152.148.169 with SMTP id tt9mr21596381lab.15.1351287823044; Fri, 26 Oct 2012 14:43:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.102.201 with HTTP; Fri, 26 Oct 2012 14:43:22 -0700 (PDT) In-Reply-To: <50848018.1040302@si6networks.com> References: <20121015183634.9221.52444.idtracker@ietfa.amsl.com> <507C5B45.6080500@si6networks.com> <50848018.1040302@si6networks.com> From: KK Date: Fri, 26 Oct 2012 14:43:22 -0700 Message-ID: To: Fernando Gont Content-Type: multipart/alternative; boundary=e89a8f23455dae907d04ccfd363e X-System-Of-Record: true X-Gm-Message-State: ALoCoQk1lKAQkzWH/9Gn95Ghw/9ecB7YPYbqICWKy7Q+QAhf0LNPbsV5cjcfzes3SsP0ARJwB95baJFmZB47pJnI8pP4fbTS8DA86cSeUlX/K/qM3qVcaWymCzQHSngmwR0ATd5/Rf+G5VZXYL/qYGNxRIvuleWv/PYxPID6OlzTxcj7SyU653wHMOhJnVH8oiRtIvCZvEdq Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New IETF I-D about VPN traffic leakages (Fwd: New Version Notification for draft-gont-opsec-vpn-leakages-00.txt) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 21:43:45 -0000 --e89a8f23455dae907d04ccfd363e Content-Type: text/plain; charset=ISO-8859-1 Hi Fernando, Sorry for the delayed response. > Agreed. But the I-D is not implying this attack scenario. -- Please do > let me know if you think this is not clear, and, in such case, where/how > I could improve the I-D. What might help is to make the scope a bit more explicit by providing the example you just gave me - """the vulnerability being discussed does not really imply that the attacker is able to get access to some resources he'd otherwise not have access to, but rather that there's a traffic leakage. e.g., if the client employs some insecure protocol (e.g., that sends user and password in the clear), he may think it's okay to use it over a VPN. But with this attack, that user/pass could end up appearing in the clear on the local network.""" Something as simple as the above text in either Section 1. or Section 4. might really help. Thanks, KK On Sun, Oct 21, 2012 at 4:07 PM, Fernando Gont wrote: > Hi, KK, > > Thanks so much for your feedback! -- Please find my comments inline... > > On 10/21/2012 04:30 PM, KK wrote: > > Some minor editorial nits and a question... > > > > Section 1. > > > > "Section 2 provides some background about IPv6 and IPv4 > > co-existence, summarizing how IPv4 and IPv4 interact on a typical > > dual-stacked network" > > > > I think you meant IPv4 and IPv6 here > [....] > > Yep -- I will fix this and the other reported nits. > > > > > Let's say user Bob wants to access his files from a file server on his > > enterprise network while enjoying a latte from a cafe. He pulls up his > > vpn client, establishes a secure connection and tries to connect to > > filer1.example.com . To me, the use of a VPN > > client implies that the server is not publicly accessible over the > > Internet. > > Agreed. But the vulnerability being discussed does not really imply that > the attacker is able to get access to some resources he'd otherwise not > have access to, but rather that there's a traffic leakage. > > e.g., if the client employs some insecure protocol (e.g., that sends > user and password in the clear), he may think it's okay to use it over a > VPN. But with this attack, that user/pass could end up appearing in the > clear on the local network. > > Another example: the user might be employing some protocol that does not > include confidentiality services (e.g., MSN) -- but the user thinks > that's still okay, since he's using that protocol over a VPN. But then > the corresponding traffic might be sent on the local network, in the clear. > > > > > Now, he gets back an A and AAAA record for filer1.example.com > > . Typically, that name would resolve to IPvX > > addresses that are only accessible from within the network. Common > > security best practices regardless of IPv4 or IPv6 would suggest that > > you achieve this by either applying appropriate filtering policies to > > prevent access from the outside world and/or only advertising prefixes > > that you want global reachability to/from. > > Agreed. But the I-D is not implying this attack scenario. -- Please do > let me know if you think this is not clear, and, in such case, where/how > I could improve the I-D. > > > > > outside world. Granted, there is still the potential of one-way > > communication attempts going out in clear text on Bob's LAN at the cafe > > and subject to interception. > > Exactly. This attack scenario, along with the case in which the client > is employing the VPN for having some sort of confidentiality at least on > the way out of the insecure network he's connecting to, are the > scenarios that this I-D is discussing. > > > > > So my question is, is the premise here that the network behind the VPN > > head end globally routable without any filtering mechanisms in place? If > > that's the case then yes, VPN leakage here can be severe and detrimental. > > Nope. For instance, the I-D is not supposed to discuss such kind of > scenario, but rather the other two attack scenarios I've mentioned above. > > Thanks! > > Best regards, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 > > > > > --e89a8f23455dae907d04ccfd363e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Fernando,
Sorry for the delayed response.<= /font>

>=A0Agreed. But the I-D is not implying this attack scenario. -- Please do=
> let me know if you think this is not clear, and, in such case= , where/how
> I could im= prove the I-D.

What might help is to make t= he scope a bit more explicit by providing the example you just gave me -=A0=

"""the vulnerabi= lity being discussed does not really imply that
the attacker is able to get access to some resources he'd othe= rwise not
<= span style=3D"font-family:arial,sans-serif;font-size:13px">have access to, = but rather that there's a traffic leakage.

e.g., if the client employs some= insecure protocol (e.g., that sends
user and passwo= rd in the clear), he may think it's okay to use it over a
VPN. But with this attack, that user/pa= ss could end up appearing in the
clear on the local network."""

Something as = simple as the above text in either Section 1. or Section 4. might really he= lp.

Thanks,
KK


<= div class=3D"gmail_quote">On Sun, Oct 21, 2012 at 4:07 PM, Fernando Gont <fgont@si6networks.com> wrote:
Hi, KK,

Thanks so much for your feedback! -- Please find my comments inline...

On 10/21/2012 04:30 PM, KK wrote:
> Some minor editorial nits and a question...
>
> Section 1.
>
> "Section 2 provides some background about IPv6 and IPv4
> co-existence, summarizing how IPv4 and IPv4 interact on a typical
> dual-stacked network"
>
> I think you meant IPv4 and IPv6 here
[....]

Yep -- I will fix this and the other reported nits.



> Let's say user Bob wants to access his files from a file server on= his
> enterprise network while enjoying a latte from a cafe. He pulls up his=
> vpn client, establishes a secure connection and tries to connect to
> filer1.e= xample.com <= http://filer1.example.com>. To me, the use of a VPN
> client implies that the server is not publicly acces= sible over the
> Internet.

Agreed. But the vulnerability being discussed does not really imply t= hat
the attacker is able to get access to some resources he'd otherwise not=
have access to, but rather that there's a traffic leakage.

e.g., if the client employs some insecure protocol (e.g., that sends
user and password in the clear), he may think it's okay to use it over = a
VPN. But with this attack, that user/pass could end up appearing in the
clear on the local network.

Another example: the user might be employing some protocol that does = not
include confidentiality services (e.g., MSN) -- but the user thinks
that's still okay, since he's using that protocol over a VPN. But t= hen
the corresponding traffic might be sent on the local network, in the clear.=



> Now, he gets back an A and AAAA record for filer1.example.com
> <http= ://filer1.example.com>. Typically, that name would resolve to IPvX
> addresses that are only accessible from within the n= etwork. Common
> security best practices regardless of IPv4 or IPv6 would suggest that<= br> > you achieve this by either applying appropriate filtering policies to<= br> > prevent access from the outside world and/or only advertising prefixes=
> that you want global reachability to/from.

Agreed. But the I-D is not implying this attack scenario. -- Please d= o
let me know if you think this is not clear, and, in such case, where/how I could improve the I-D.



> outside world. Granted, there is still the potential of one-way
> communication attempts going out in clear text on Bob's LAN at the= cafe
> and subject to interception.

Exactly. This attack scenario, along with the case in which the clien= t
is employing the VPN for having some sort of confidentiality at least on the way out of the insecure network he's connecting to, are the
scenarios that this I-D is discussing.



> So my question is, is the premise here that the network behind the VPN=
> head end globally routable without any filtering mechanisms in place? = If
> that's the case then yes, VPN leakage here can be severe and detri= mental.

Nope. For instance, the I-D is not supposed to discuss such kind of scenario, but rather the other two attack scenarios I've mentioned abov= e.

Thanks!

Best regards,
--
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com<= br> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492





--e89a8f23455dae907d04ccfd363e-- From cb.list6@gmail.com Sat Oct 27 14:10:51 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7226B21F854F for ; Sat, 27 Oct 2012 14:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaOfWPoO5VNN for ; Sat, 27 Oct 2012 14:10:51 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A411821F8540 for ; Sat, 27 Oct 2012 14:10:47 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3378514lam.31 for ; Sat, 27 Oct 2012 14:10: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=AR5iKp9JOJ0PY1nSICWkP3JJORJPmDJnKHXWoNmLx/o=; b=Nwt52BpvemUXoEXoE7OiA6MOoFpgV10A9Go72dboVG9x8zxiaRPXM764y+/eGKrljD dXmNnak2LwWc8w6vyUMf0eSdTs8IELBki5elBqR4GwtnxZfoQunSPkKBLwyv0I/9AVTj cTrV4XLsy7ZI9rM1Ilyga60J9EA/JF8ZrDKXvgMdtf9Wds+rPb0ThPMFZ7kVxLmQjHiJ VEYCa44UbRmUnR2FlMjkq+vaZrFhLGPc8j/IYx5Twp/ktjaQAHaquynglh5d46tZtD+B jnR0xnZM37FphdPzVn0Nqq0xFdGdO4mfTaVT/bvFYhMp3eK1isjCAY2TvifWa8sJLaWr +dzA== MIME-Version: 1.0 Received: by 10.152.104.107 with SMTP id gd11mr23272874lab.25.1351372246480; Sat, 27 Oct 2012 14:10:46 -0700 (PDT) Received: by 10.112.81.167 with HTTP; Sat, 27 Oct 2012 14:10:46 -0700 (PDT) In-Reply-To: <507C5B45.6080500@si6networks.com> References: <20121015183634.9221.52444.idtracker@ietfa.amsl.com> <507C5B45.6080500@si6networks.com> Date: Sat, 27 Oct 2012 14:10:46 -0700 Message-ID: From: Cameron Byrne To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New IETF I-D about VPN traffic leakages (Fwd: New Version Notification for draft-gont-opsec-vpn-leakages-00.txt) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 21:10:51 -0000 Hi, On Mon, Oct 15, 2012 at 11:51 AM, Fernando Gont wrote: > Hi, folks, > > > We have published a new IETF I-D that discusses the VPN traffic-leakage > issues that was briefly discussed on this mailing-list a few weeks ago. > > The I-D is available at: > > > Any feedback will be really welcome. The attack that i am most concerned about is that many folks assume the VPN will "lock the stack". And, the VPN software may in fact lock the IPv4 stack (on the WAN, only traffic to and from the VPN endpoints is allowed). But, in the case of dual stack, the VPN locks the IPv4 stack and the IPv6 stack is left wide open to a public WLAN. So, the attacker at a coffee shop can own the VPN users system via IPv6 and therefore access the secure corporate network over IPv4. This is not a case of protocol translation or traffic leaking, but a case of using a "jump host" to illicitly move from a public WLAN to a secure corporate network. I think there is also some additional ipv6 nuance that can be explored in this case of a dual-stack VPN. For example, how is LLA treated on the coffee shop WLAN? Also, the name server issue can be explored, if RA or DHCPv6 provides a DNS server, the VPN client should be sure to not use those since a rogue DNS server can create a situation where VPN traffic is leaked.... http://intranet is spoofed by the local attacker DNS server and skims login creds CB From fgont@si6networks.com Sat Oct 27 14:25:18 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4035D21F8529 for ; Sat, 27 Oct 2012 14:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQV1vvwKlYAX for ; Sat, 27 Oct 2012 14:25:17 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id B3DF321F851C for ; Sat, 27 Oct 2012 14:25:17 -0700 (PDT) Received: from [216.130.36.186] (helo=[10.154.150.59]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TSDsX-0006fX-1N; Sat, 27 Oct 2012 23:25:14 +0200 Message-ID: <508C511D.8060707@si6networks.com> Date: Sat, 27 Oct 2012 18:24:45 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: KK References: <20121015183634.9221.52444.idtracker@ietfa.amsl.com> <507C5B45.6080500@si6networks.com> <50848018.1040302@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New IETF I-D about VPN traffic leakages (Fwd: New Version Notification for draft-gont-opsec-vpn-leakages-00.txt) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 21:25:18 -0000 Hi, KK, On 10/26/2012 06:43 PM, KK wrote: >> Agreed. But the I-D is not implying this attack scenario. -- Please do >> let me know if you think this is not clear, and, in such case, where/how >> I could improve the I-D. > > What might help is to make the scope a bit more explicit by providing > the example you just gave me - > > """the vulnerability being discussed does not really imply that > the attacker is able to get access to some resources he'd otherwise not > have access to, but rather that there's a traffic leakage. > > e.g., if the client employs some insecure protocol (e.g., that sends > user and password in the clear), he may think it's okay to use it over a > VPN. But with this attack, that user/pass could end up appearing in the > clear on the local network.""" > > Something as simple as the above text in either Section 1. or Section 4. > might really help. Okay. I will incorporate this into the next rev. 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 fgont@si6networks.com Sun Oct 28 14:18:46 2012 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716F421F855F for ; Sun, 28 Oct 2012 14:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuHGwxhrDKsw for ; Sun, 28 Oct 2012 14:18:46 -0700 (PDT) Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id DCD8421F855C for ; Sun, 28 Oct 2012 14:18:45 -0700 (PDT) Received: from r190-134-9-106.dialup.adsl.anteldata.net.uy ([190.134.9.106] helo=[10.10.10.130]) by web01.jbserver.net with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1TSaFi-0007Gf-65; Sun, 28 Oct 2012 22:18:38 +0100 Message-ID: <508C6E0E.9010100@si6networks.com> Date: Sat, 27 Oct 2012 20:28:14 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: Cameron Byrne References: <20121015183634.9221.52444.idtracker@ietfa.amsl.com> <507C5B45.6080500@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "opsec@ietf.org" Subject: Re: [OPSEC] New IETF I-D about VPN traffic leakages (Fwd: New Version Notification for draft-gont-opsec-vpn-leakages-00.txt) X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Oct 2012 21:18:46 -0000 Hi, Cameron, Thanks so much for your feedback! Please find my comments in-line.... On 10/27/2012 06:10 PM, Cameron Byrne wrote: > The attack that i am most concerned about is that many folks assume > the VPN will "lock the stack". And, the VPN software may in fact lock > the IPv4 stack (on the WAN, only traffic to and from the VPN endpoints > is allowed). But, in the case of dual stack, the VPN locks the IPv4 > stack and the IPv6 stack is left wide open to a public WLAN. So, the > attacker at a coffee shop can own the VPN users system via IPv6 and > therefore access the secure corporate network over IPv4. This is not > a case of protocol translation or traffic leaking, but a case of using > a "jump host" to illicitly move from a public WLAN to a secure > corporate network. Agreed. It looks like I should probably change the title of the I-D to something along the lines of "Security Implications of dual-stack hosts/networks on Virtual Private Networks (VPN)" or "Security Issues of Virtual Private Networks (VPN) in dual-stack hosts/ networks" ? (please do let me know if you have any preference of title over the other, or feel free to suggest an alternative title) Then the I-D could mention possible/common security implications such: * Lost of confidentiality in the resulting traffic (i.e., you thought your traffic was protected from eavesdroppers, when in fact it wasn't) * The possibility of an attacker stealing credentials (e.g. if an insecure protocol was sending user/pass in the clear) * And the attack scenario you describing (an attacker using the VPN as a pivot to attack some system in the VPN). > I think there is also some additional ipv6 nuance that can be explored > in this case of a dual-stack VPN. For example, how is LLA treated on > the coffee shop WLAN? In what sense? > Also, the name server issue can be explored, > if RA or DHCPv6 provides a DNS server, the VPN client should be sure > to not use those since a rogue DNS server can create a situation where > VPN traffic is leaked.... http://intranet is spoofed by the local > attacker DNS server and skims login creds Agreed. I will try to test common implementations (Windows, *BSD, Solaris, and Linux) with respect to this issue, and provide a summary. Thanks so much for your feedback! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492