From gvandeve@cisco.com Tue Nov 5 11:21:54 2013 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 4CFD311E8142 for ; Tue, 5 Nov 2013 11:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MB2w+sQBTU85 for ; Tue, 5 Nov 2013 11:21:37 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBE511E81EC for ; Tue, 5 Nov 2013 11:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2943; q=dns/txt; s=iport; t=1383679251; x=1384888851; h=from:to:subject:date:message-id:mime-version; bh=jeAvAN8avtNvDhWVYYZqilgO+mhCZOOBtmNH/RjXKPw=; b=UvS2FRia5sbpqBBdvYb1boP3pp+XgspmCv65XZRW5F30JcgLMHnUrab9 VnNabUvPWfoqzIKetSe2H6SWX/D7EBSn6N4495vzbOIcvIdWideOjEZnB GIcPGYAl8780zPO9/5kjDjbP/8P2fa+d7XmAjsTVb9FA4HSvmsx8n1FKR E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8GADdEeVKtJV2a/2dsb2JhbABZgkNEOFO/OIEsFm0HgicBBC1eAQweViYBBBuHeZ0toVWPKINYgQ8DqhODJoIq X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="scan'208,217";a="281079427" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 05 Nov 2013 19:20:50 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rA5JKoZN031262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 5 Nov 2013 19:20:50 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.149]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 13:20:50 -0600 From: "Gunter Van de Velde (gvandeve)" To: "opsec@ietf.org" Thread-Topic: IETF88 Minutes and Jabber scribe takers Thread-Index: Ac7aW+LFrEO2t/b1R/q/o8jkpoCyXA== Date: Tue, 5 Nov 2013 19:20:49 +0000 Message-ID: <67832B1175062E48926BF3CB27C49B240D308C90@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.171.116] Content-Type: multipart/alternative; boundary="_000_67832B1175062E48926BF3CB27C49B240D308C90xmbalnx12ciscoc_" MIME-Version: 1.0 Subject: [OPSEC] IETF88 Minutes and Jabber scribe takers 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, 05 Nov 2013 19:21:54 -0000 --_000_67832B1175062E48926BF3CB27C49B240D308C90xmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, This is your chance to be famous in OPSEC. The chairs are looking for volunteers to function as scribe and minute take= r. Kindly let us know if you are willing to volunteer, Brgds, G/, KK & Warren --_000_67832B1175062E48926BF3CB27C49B240D308C90xmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

This is your chance to be famous in OPSEC.

 

The chairs are looking for volunteers to function as= scribe and minute taker.

 

Kindly let us know if you are willing to volunteer,<= o:p>

 

Brgds,

G/, KK & Warren

 

--_000_67832B1175062E48926BF3CB27C49B240D308C90xmbalnx12ciscoc_-- From warren@kumari.net Wed Nov 6 18:43:49 2013 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 6588121E81C8 for ; Wed, 6 Nov 2013 18:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrlRY1ozgRXZ for ; Wed, 6 Nov 2013 18:43:43 -0800 (PST) Received: from vimes.kumari.net (smtp1.kumari.net [204.194.22.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEA021E81E3 for ; Wed, 6 Nov 2013 18:38:40 -0800 (PST) Received: from [31.130.224.158] (unknown [31.130.224.158]) by vimes.kumari.net (Postfix) with ESMTPSA id 400681B4046D; Wed, 6 Nov 2013 21:38:39 -0500 (EST) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Nov 2013 18:38:38 -0800 Message-Id: To: opsec WG Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Cc: Warren Kumari Subject: [OPSEC] Minutes posted. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 02:43:49 -0000 Hi all, We have just posted the OpSec WG minutes[0]. Please let us know if we = misunderstood / misrepresented your comments. W [0]: Thanks again to Paul Hoffman. -- It is impossible to sharpen a pencil with a blunt axe. It is equally = vain to try to do it with ten blunt axes instead. -- E.W Dijkstra, 1930-2002 From furry13@gmail.com Fri Nov 8 12:04:46 2013 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 1922011E81B6 for ; Fri, 8 Nov 2013 12:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YX-HZgjXRwyC for ; Fri, 8 Nov 2013 12:04:45 -0800 (PST) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id A032621E8179 for ; Fri, 8 Nov 2013 12:04:39 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id k4so2098222qaq.5 for ; Fri, 08 Nov 2013 12:04:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=12pIFt7OBr2eVmoUzizfKXlyrBiMPj9ROA4iuXa8fZs=; b=aFfAr0AN1xQNcrjCtdHMfN631QlfrWSVgb9PNKilQw6mW9U09niSts+38a7RXzPAXl aaTFmZ6L7FJ0AAs6IP+antC9sgdfKt8Xz+IV1j7UOgbsroYhIdaUUPokpBRPIxYn4hRn gdhRnMqwUOIM3hVF+JkTT2X46jaFFYGi5SKnaPC/ggm40PS3tQtnQstAUk4xReQaSrpX 03YWxRcprt1bgc0WLFMLh6LBEA5seyNd0otReK3nXVjkJq5AouhMLI2UVsdqEc8oH88r bGyyK5dLvSXA+li4go4FCm9/XdsTvoVvdBasW2TNZQu0jI5ScmABno3cat+5im6FiiHX 9YeA== X-Received: by 10.49.94.226 with SMTP id df2mr25612573qeb.76.1383941079083; Fri, 08 Nov 2013 12:04:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.100.195 with HTTP; Fri, 8 Nov 2013 12:04:19 -0800 (PST) In-Reply-To: References: From: Jen Linkova Date: Fri, 8 Nov 2013 21:04:19 +0100 Message-ID: To: Warren Kumari Content-Type: text/plain; charset=ISO-8859-1 Cc: opsec WG Subject: Re: [OPSEC] Minutes posted. X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:04:46 -0000 On Thu, Nov 7, 2013 at 3:38 AM, Warren Kumari wrote: > We have just posted the OpSec WG minutes[0]. Please let us know if we misunderstood / misrepresented your comments. "Jen Linkova: a question about using LL sources for links that are off-link" s/for links/for destinations/ -- SY, Jen Linkova aka Furry From furry13@gmail.com Thu Nov 14 09:23:18 2013 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 310BD21E80F1 for ; Thu, 14 Nov 2013 09:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJ54bPvw7WSN for ; Thu, 14 Nov 2013 09:23:17 -0800 (PST) Received: from mail-qe0-x234.google.com (mail-qe0-x234.google.com [IPv6:2607:f8b0:400d:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 48CB021E8056 for ; Thu, 14 Nov 2013 09:23:17 -0800 (PST) Received: by mail-qe0-f52.google.com with SMTP id cz11so1001227qeb.39 for ; Thu, 14 Nov 2013 09:23:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=8K2cnlcrp8KDjCtVzVg2dC6SJPjitJ8jfof1hh7CihI=; b=MIdjE6lAOZ+JxU/e5qErvGql10EXb3XxWQST15QrMkwm5Ore5nySlKS0tRvtZN18Ge Em2bQ4WWeRyG1KBdQvtvBl7Ppt9y2z46SorlL55OBLW8LbihBQ9erFlzqPiom2+eQQir LHE4ZJHS39qZlVmbK38aqGVrZ20SFPCd9blhWGnKbB3gvPXWCETeOV5jAF1qyHQZVFly WtjV671OsergNr1hHYCBQFa0eDeFwZ24Gb+A7RH1GISdxS95aBGStOZ7L6YYDtQLN18d c9vXTdq9bMwY9a0JDe9pxVr9HbluLGxRP6VbDVFuZDTQSjTM+qt9FEktySXzJGQcjxHX haDQ== X-Received: by 10.229.101.74 with SMTP id b10mr4116536qco.8.1384449793845; Thu, 14 Nov 2013 09:23:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.101.202 with HTTP; Thu, 14 Nov 2013 09:22:53 -0800 (PST) From: Jen Linkova Date: Thu, 14 Nov 2013 18:22:53 +0100 Message-ID: To: opsec WG , Eric Vyncke , Michael Behringer Content-Type: text/plain; charset=ISO-8859-1 Subject: [OPSEC] comments on draft-ietf-opsec-lla-only-04 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, 14 Nov 2013 17:23:18 -0000 Hello, I've reviewed draft-ietf-opsec-lla-only-04, see my comments below. 1) 2.1. The Approach "Neither global IPv6 addresses nor unique local addresses are configured on infrastructure links. " [comment] Formally ULAs are of the global scope so maybe re-phrasing to "neither globally routed addresses nor unique local addresses". 2) 2.1. The Approach " [RFC6724] mandates that greater than link-local scope IPv6 addresses must be used as the source IPv6 address for all generated ICMPv6 messages sent to a non link-local address. " [comment] As I mentioned in Vancouver, I think this statement is not absolutely accurate. What RFC6724 mandates is that *if* candidate source addresses set contains link-local and global addresses, then global address is preferred for global destinations. Therefore it is possible to chose link-local source for global destination in some cases. For example, ND redirects MUST be sent from link-local address (RFC4861, Section 4.5) while the destination may be global address. Speaking of candidate set for DAS.. RFC6724 says: "It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination (the "outgoing" interface). On routers, the candidate set MAY include unicast addresses assigned to any interface that forwards packets, subject to the restrictions described below. Implementations that wish to support the use of global source addresses assigned to a loopback interface MUST behave as if the loopback interface originates and forwards the packet." Which means that it some implementations might not include lo0 into the candidate set, in which case a router might use link-local as a source which leads to operational issues and makes the troubleshooting more difficult. I think it worth be discussed in the 'Caveats' section. 3) 2.1. The Approach "Control plane protocols, such as BGP [RFC4271], ISIS [IS-IS], OSPFv3 [RFC5340], RIPng [RFC2080], PIM [RFC4609] work by default or can be configured to work with link-local addresses....... We therefore conclude that it is possible to construct a working network in this way." [comment] However there are protocols which may experience issues in such topology (RSVP). While you do mention RSVP later, this section discusses the effect on specific traffic types, so I'd suggest that you add a sentence or two about protocols which might not work and clarify that it is possible to construct a working network if those protocols are not in use. 4) 2.1. The Approach "ICMP error message can be sourced from a loopback interface. They must not be sourced from link-local addresses when the destination is non link-local." See my comment #2 - applies here as well. 5) 2.2. Advantages [comment] If I were you, I'd reordered the paragraphs. IMHO, lower configuration complexity & simpler DNS are the main advantages of the suggested approach, then routing table reduction. Reducing attack surface does not sound like a really big advantage providing that risk can easily be mitigated - so probably it would make sense to put it at the end of the section. What do you think? "Lower configuration complexity: link-local addresses require no specific configuration, thereby lowering the complexity and size of router configurations. This also reduces the likelihood of configuration mistakes." [comment] I'd also mention that it simplifies the whole address management process. 6)2.3. Caveats " Traceroute: similar to the ping case, a reply to a traceroute packet would come from the address of a loopback interface, and current implementations do not display the specific interface the packets came in on. Also here, RFC5837 [RFC5837] provides a solution. " [comment] in the traceroute/ping section you are saying that RFC5837 provides a solution. However there are two problems and only one might be solved by including interface identifier into ICMPv6. The first problem is to *see* which interface the packet arrived via. RFC5837 does help with it. The second issue is that we are losing the ability to control the path of the packet and specify which interface the traceroute/ping packet should arrive on. It is especially useful for packet loss troubleshooting. Would it be possible to clarify that RFC5837 provided only partical solution? 7) 2.3. Caveats " Hardware dependency:..... LLAs can be statically configured such as fe80::1 and fe80::2 which can be used to configure any required static routing neighborship. This static configuration is similar in complexity to statically configured greater than link-local addresses" [comment] I'd say that the complexity is higher as such approach introduces an additional complexity in monitoring/troubleshooting. Such configuration results in situation when an operator has to deal with messages like 'BGP neighbor fe80::1%ae1 is down' which might be confusing and requires additional efforts to identify neighbors. This also applies to the next paragraph about NMS toolkit: an operator needs to ensure that NMS and other tools support link-local addresses not just for router interfaces but for protocol configuration (such as BGP peers etc). 8) 2.4. Internet Exchange Points [comment] It would be great to see two subsection discussing advantages and caveats like it is done above. Typos found: 1) 1. Introduction s/OPSF/OSPF/ 2) 2.3. Caveats s/implementions/implementations/ -- SY, Jen Linkova aka Furry From opsec@wjcerveny.com Mon Nov 18 14:10:06 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74DD1AE632 for ; Mon, 18 Nov 2013 14:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_1tggUT_1aJ for ; Mon, 18 Nov 2013 14:10:05 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id EE9A51AE630 for ; Mon, 18 Nov 2013 14:10:04 -0800 (PST) Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 7394721104 for ; Mon, 18 Nov 2013 17:09:54 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute5.internal (MEProxy); Mon, 18 Nov 2013 17:09:56 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=from:content-type :content-transfer-encoding:subject:message-id:date:to :mime-version; s=smtpout; bh=zUIA0TgstP8RWp/Ed+2pENzdKks=; b=sOt heohYtP0owHxT5DS6lW8QvKUI6K1la8vTdBVkzfzayLDPxVpmzD159D+6tUoluCM EgOpJGwYHkIAwRrEYAzDJ/cVbLpY7mSDkdnBBcTvYzCsz2v0n12DyR2xKTmUapK1 u2YBaWixBIXfrPwKeR5v693//kAz4oTodm9CKEv4= X-Sasl-enc: LiJT6I7DUnqyH80PaQ4g5SWjRZVChbBya+cEkAFdLkeE 1384812594 Received: from [192.168.1.108] (unknown [96.35.101.227]) by mail.messagingengine.com (Postfix) with ESMTPA id 7A3D86800C0 for ; Mon, 18 Nov 2013 17:09:54 -0500 (EST) From: Bill Cerveny Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 18 Nov 2013 17:09:55 -0500 To: opsec@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Subject: [OPSEC] Comments on draft-ietf-opsec-lla-only-04.xml X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 22:10:07 -0000 I've reviewed draft-ietf-opsec-lla-only-04. I've sent my detailed = suggested revisions and comments directly to the authors, but at a high = level: 1) The introduction makes reference to RFC6860 regarding OSPFv2 and = OSPFv3, but then doesn't mention this in the rest of the document. Why = is this in the introduction? Why is this not mentioned in the rest of = the document? 2) I'm not sure if it is common knowledge what is intended by phrase, = "greater than link-local-scope", or at least I wasn't familiar with it. = Minimally, can the document include a reference to how "greater" or = "less than" is used in terms of address types? 3) At the end of the document, you make reference to "the traditional = approach". I don't think you've clarified what you mean by "the = traditional approach", although I can guess what you've meant. Bill Cerveny= From internet-drafts@ietf.org Fri Nov 22 04:50:25 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D37D1AE035; Fri, 22 Nov 2013 04:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCGPXG_YsDix; Fri, 22 Nov 2013 04:50:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC3D1AD9B8; Fri, 22 Nov 2013 04:50:23 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131122125023.16611.21274.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 04:50:23 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ip-options-filtering-06.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 12:50:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : Recommendations on filtering of IPv4 packets containing = IPv4 options. Author(s) : Fernando Gont RJ Atkinson Carlos Pignataro Filename : draft-ietf-opsec-ip-options-filtering-06.txt Pages : 34 Date : 2013-11-22 Abstract: This document provides advice on the filtering of IPv4 packets based on the IPv4 options they contain. Additionally, it discusses the operational and interoperability implications of dropping packets based on the IP options they contain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ip-options-filtering-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ip-options-filtering-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From evyncke@cisco.com Mon Nov 25 04:26:27 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993B31AD957 for ; Mon, 25 Nov 2013 04:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-_3oJaNVzsD for ; Mon, 25 Nov 2013 04:26:26 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id F27551AD93D for ; Mon, 25 Nov 2013 04:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1735; q=dns/txt; s=iport; t=1385382386; x=1386591986; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=81U3bYyhzsRxnxHSd4iJR3jl6S/2KXmMUH6tt06suwg=; b=IsM5JpjaPmYyaECmA5Ph3Qg66tUSfREBP3PHu6CfHLr5I5VqSWRdqTY+ kKLjnmrj6orihn4ryIotdQI5EG/+1n+gwOTLk1ny3cZQ7Q6xwDNvpXoVW jnh1pgxIwhvWzNjNMWURTRVG2EhW70Z9+GozGiq6VW9tcN7DS44gXfxnU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAB9Bk1KtJV2Z/2dsb2JhbABZgwc4U7wmgSsWdIIlAQEBBAEBAWsXBAIBCA4DBAEBCx0HJwsUCQgCBAESCId5Db1YEwSOVjgGgxqBEwOJCqEcgyiCKg X-IronPort-AV: E=Sophos;i="4.93,767,1378857600"; d="scan'208";a="2003268" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 25 Nov 2013 12:26:26 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAPCQQRA028274 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 12:26:26 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Mon, 25 Nov 2013 06:26:25 -0600 From: "Eric Vyncke (evyncke)" To: Bill Cerveny , "opsec@ietf.org" Thread-Topic: [OPSEC] Comments on draft-ietf-opsec-lla-only-04.xml Thread-Index: AQHO5KrxDmv2yqYKjk+E7gKLaf0Ru5o16bVg Date: Mon, 25 Nov 2013 12:26:25 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E1237FE51B@xmb-aln-x02.cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] Comments on draft-ietf-opsec-lla-only-04.xml X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 12:26:27 -0000 Bill Thanks for your comments, Michael and I just went through all of them and h= ere are our own feedback. - cosmetic and typos are fixed now (MANY thanks) as well as your suggestion= s to improved readability - we moved RFC 6860 short text from the introduction to approach section - RFC 4443 specifies when to send the ICMP message, so, we left the text un= changed And of course, we added your name in the acknowledgement section -=E9ric & michael > -----Original Message----- > From: OPSEC [mailto:opsec-bounces@ietf.org] On Behalf Of Bill Cerveny > Sent: lundi 18 novembre 2013 23:10 > To: opsec@ietf.org > Subject: [OPSEC] Comments on draft-ietf-opsec-lla-only-04.xml >=20 > I've reviewed draft-ietf-opsec-lla-only-04. I've sent my detailed > suggested revisions and comments directly to the authors, but at a > high level: >=20 > 1) The introduction makes reference to RFC6860 regarding OSPFv2 and > OSPFv3, but then doesn't mention this in the rest of the document. > Why is this in the introduction? Why is this not mentioned in the > rest of the document? > 2) I'm not sure if it is common knowledge what is intended by phrase, > "greater than link-local-scope", or at least I wasn't familiar with > it. Minimally, can the document include a reference to how "greater" > or "less than" is used in terms of address types? > 3) At the end of the document, you make reference to "the traditional > approach". I don't think you've clarified what you mean by "the > traditional approach", although I can guess what you've meant. >=20 > Bill Cerveny > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec From evyncke@cisco.com Mon Nov 25 05:54:18 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0471AD957 for ; Mon, 25 Nov 2013 05:54:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.902 X-Spam-Level: X-Spam-Status: No, score=-8.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzR2I25nikcq for ; Mon, 25 Nov 2013 05:54:16 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id DF3B81AD6A4 for ; Mon, 25 Nov 2013 05:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1682; q=dns/txt; s=iport; t=1385387656; x=1386597256; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=oo9FK/Fay5Z/cYyZSicVzQIeVlLxz6aXyjC3z/XUNw4=; b=lt1B/NxrOM+M8+5iIdu5vCyvMs1kefHq6IPLjRj9DUWLzfzGw6shBC7T oZjxyxCnZCMXpWLlctyKHBryPMtT3GJnEW+Qftioagvd54hIUb+owV94p r/OvKRvli7kVQK0getDt/BMMV9ZTux9Q6Je4wg8jIrqsTG3yAXEC6MfwS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFAFlVk1KtJXG8/2dsb2JhbABZgweBC7wngSsWdIIlAQEBBIEFBAIBCA4DBAEBAQodBzIUCQgCBAESCId5vXwXjlY4BoMagRMDiQqhHIMogio X-IronPort-AV: E=Sophos;i="4.93,768,1378857600"; d="scan'208";a="2023515" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-6.cisco.com with ESMTP; 25 Nov 2013 13:54:15 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAPDsFNN020985 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Nov 2013 13:54:15 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Mon, 25 Nov 2013 07:54:14 -0600 From: "Eric Vyncke (evyncke)" To: Fernando Gont , "opsec@ietf.org" Thread-Topic: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-04.txt Thread-Index: AQHOzSBW2t1F3gdMiEC1EuKVNWHvtZn9TadggALiJ4CANc5L4A== Date: Mon, 25 Nov 2013 13:54:14 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E1237FE76E@xmb-aln-x02.cisco.com> References: <20131019230954.9604.42688.idtracker@ietfa.amsl.com> <97EB7536A2B2C549846804BBF3FD47E12379401D@xmb-aln-x02.cisco.com> <5265C277.20807@si6networks.com> In-Reply-To: <5265C277.20807@si6networks.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-04.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 13:54:18 -0000 Fernando Michael and I are doing a last( ?) pass on our I-D, and coming back to your= stable-privacy-address (which I like) relevance to the LLA-only ID. Regard= ing LLA, I have only seen three cases (by routers and end hosts): - EUI-64 based (typical for routers) - static (rare but doable) - random but permanent (such as Windows -- quite similar to your draft but = LLA are never changing) So, I do not think we should go in details around this aspect of LLA as it = is orthogonal to our LLA-only approach. Thanks again for all the other comments which made their ways in -04 -=E9ric & michael > -----Original Message----- > From: Fernando Gont [mailto:fgont@si6networks.com] > Sent: mardi 22 octobre 2013 02:11 > To: Eric Vyncke (evyncke); opsec@ietf.org > Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-lla-only-04.txt >=20 > Hi, Eric, >=20 > On 10/20/2013 02:44 PM, Eric Vyncke (evyncke) wrote: > > document. Added reference to RFC 4987 (SYN flood). Clarification > about > > what is meant by a loopback address/interface. The comment about > > static addresses for LLA and draft-ietf-6man-stable-privacy- > addresses > > has been ignored because to our knowledge routers never use privacy > > extension addresses for their interfaces. >=20 > You mean slaac? What about link-local addresses? >=20 > Anyway... has this doc been WGLC'ed? If not, I volunteer fore > reviewing the document again (*if* such reviews are needed to > progress the I-D :-) ). >=20 > Cheers, > -- > Fernando Gont > SI6 Networks > e-mail: fgont@si6networks.com > PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >=20 >=20 >=20 From internet-drafts@ietf.org Tue Nov 26 00:05:20 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01651A1F3F; Tue, 26 Nov 2013 00:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpS_9_Fy6Edw; Tue, 26 Nov 2013 00:05:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E185C1A1F19; Tue, 26 Nov 2013 00:05:17 -0800 (PST) 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.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131126080517.9772.6509.idtracker@ietfa.amsl.com> Date: Tue, 26 Nov 2013 00:05:17 -0800 Cc: opsec@ietf.org Subject: [OPSEC] I-D Action: draft-ietf-opsec-ipv6-implications-on-ipv4-nets-06.txt X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 08:05:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Operational Security Capabilities for IP = Network Infrastructure Working Group of the IETF. Title : Security Implications of IPv6 on IPv4 Networks Author(s) : Fernando Gont Will (Shucheng) Liu Filename : draft-ietf-opsec-ipv6-implications-on-ipv4-nets-06.txt Pages : 18 Date : 2013-11-25 Abstract: This document discusses the security implications of native IPv6 support and IPv6 transition/co-existence technologies on "IPv4-only" networks, and describes possible mitigations for the aforementioned issues. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4= -nets There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-= 06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-opsec-ipv6-implications-on-ip= v4-nets-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From evyncke@cisco.com Tue Nov 26 02:07:02 2013 Return-Path: X-Original-To: opsec@ietfa.amsl.com Delivered-To: opsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAB11AE101 for ; Tue, 26 Nov 2013 02:07:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5UOW3OayeRp for ; Tue, 26 Nov 2013 02:07:00 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id EEDAB1AD698 for ; Tue, 26 Nov 2013 02:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7068; q=dns/txt; s=iport; t=1385460420; x=1386670020; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=GTfL5uiCv8rEFQ6+frW1KBPT68JHgx3YX4lduClm++A=; b=dgq2OoVdc15WKUdiosCOMj2xJ2UPGb0akBP85BBEOkyfM8k23Errknt+ 0MbFnhvlrnSkTxX3nzjCj44WdO7A+0p3HYYwMUs4NscbSMdT+3+T+IKBP ieaZqKRjkpDDRHT0rh2p2cjW2MR8NYsFsoN9jMhlka+SqTNWKVsm5bxWs o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAB1ylFKtJV2a/2dsb2JhbABPCoMHgQu8FoEqFnSCJQEBAQSBBQQCAQgOAwQBAQsdByERFAkIAgQBEggTh1QDD7cbDYgHF4xngTMrOAaDGoETA4kKiyeBeI5EhTiDKIIq X-IronPort-AV: E=Sophos;i="4.93,773,1378857600"; d="scan'208";a="2279325" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP; 26 Nov 2013 10:06:54 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAQA6stL016081 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Nov 2013 10:06:54 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.231]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 04:06:53 -0600 From: "Eric Vyncke (evyncke)" To: Jen Linkova , opsec WG , "Michael Behringer (mbehring)" Thread-Topic: comments on draft-ietf-opsec-lla-only-04 Thread-Index: AQHO4V467lLZSAd2QUOGmxj7j4jJqpo3SpBg Date: Tue, 26 Nov 2013 10:06:53 +0000 Message-ID: <97EB7536A2B2C549846804BBF3FD47E1237FF9FA@xmb-aln-x02.cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.185.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [OPSEC] comments on draft-ietf-opsec-lla-only-04 X-BeenThere: opsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: opsec wg mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 10:07:02 -0000 Hello Jen Thanks for your interest for our I-D and even more thanks for your valuable= comments. 1) accepted 2) point taken for redirect message & use of loopback address being impleme= ntation dependent, we have modified this section 3) Control plane protocols, we now use 'Most control plane protocols' as RS= VP is an exception ;-) 4) Same as 2) indeed 5) added that the order of advantage has no significance and added the 'Sim= pler address management' as suggestion (thanks) 6) good catch, traceroute text has been changed 7) static LLA configuration text has been modified 8) IXP, we preferred not to call out advantages and caveats as they previou= s ones also apply to IXP Again big thanks -=E9ric > -----Original Message----- > From: Jen Linkova [mailto:furry13@gmail.com] > Sent: jeudi 14 novembre 2013 18:23 > To: opsec WG; Eric Vyncke (evyncke); Michael Behringer (mbehring) > Subject: comments on draft-ietf-opsec-lla-only-04 >=20 > Hello, >=20 > I've reviewed draft-ietf-opsec-lla-only-04, see my comments below. >=20 >=20 > 1) 2.1. The Approach >=20 > "Neither global IPv6 addresses nor unique local addresses are > configured on infrastructure links. " >=20 > [comment] Formally ULAs are of the global scope so maybe re-phrasing to > "neither globally routed addresses nor unique local addresses". >=20 >=20 > 2) 2.1. The Approach > " [RFC6724] mandates that greater than link-local scope IPv6 addresses > must be used as the source IPv6 address for all generated ICMPv6 > messages sent to a non link-local address. > " >=20 > [comment] As I mentioned in Vancouver, I think this statement is not > absolutely accurate. > What RFC6724 mandates is that *if* candidate source addresses set contain= s > link-local and global addresses, then global address is preferred for > global destinations. > Therefore it is possible to chose link-local source for global destinatio= n > in some cases. > For example, ND redirects MUST be sent from link-local address (RFC4861, > Section 4.5) while the destination may be global address. > Speaking of candidate set for DAS.. > RFC6724 says: > "It is RECOMMENDED that the candidate source addresses be the set of > unicast addresses assigned to the interface that will be used to send > to the destination (the "outgoing" interface). On routers, the > candidate set MAY include unicast addresses assigned to any interface > that forwards packets, subject to the restrictions described below. > Implementations that wish to support the use of global source > addresses assigned to a loopback interface MUST behave as if the > loopback interface originates and forwards the packet." >=20 > Which means that it some implementations might not include lo0 into the > candidate set, in which case a router might use link-local as a source > which leads to operational issues and makes the troubleshooting more > difficult. I think it worth be discussed in the 'Caveats' > section. >=20 > 3) 2.1. The Approach > "Control plane protocols, such as BGP [RFC4271], ISIS [IS-IS], > OSPFv3 [RFC5340], RIPng [RFC2080], PIM [RFC4609] work by default > or can be configured to work with link-local addresses....... > We therefore conclude that it is possible to construct a working > network in this way." >=20 > [comment] However there are protocols which may experience issues in such > topology (RSVP). While you do mention RSVP later, this section discusses > the effect on specific traffic types, so I'd suggest that you add a > sentence or two about protocols which might not work and clarify that it > is possible to construct a working network if those protocols are not in > use. >=20 > 4) 2.1. The Approach > "ICMP error message can be sourced from a loopback interface. They > must not be sourced from link-local addresses when the destination > is non link-local." >=20 > See my comment #2 - applies here as well. >=20 >=20 > 5) 2.2. Advantages > [comment] If I were you, I'd reordered the paragraphs. IMHO, lower > configuration complexity & simpler DNS are the main advantages of the > suggested approach, then routing table reduction. > Reducing attack surface does not sound like a really big advantage > providing that risk can easily be mitigated - so probably it would make > sense to put it at the end of the section. What do you think? >=20 > "Lower configuration complexity: link-local addresses require no > specific configuration, thereby lowering the complexity and size of > router configurations. This also reduces the likelihood of > configuration mistakes." >=20 > [comment] I'd also mention that it simplifies the whole address managemen= t > process. >=20 > 6)2.3. Caveats >=20 > " > Traceroute: similar to the ping case, a reply to a traceroute packet > would come from the address of a loopback interface, and current > implementations do not display the specific interface the packets > came in on. Also here, RFC5837 [RFC5837] provides a solution. > " >=20 > [comment] in the traceroute/ping section you are saying that RFC5837 > provides a solution. > However there are two problems and only one might be solved by including > interface identifier into ICMPv6. The first problem is to > *see* which interface the packet arrived via. RFC5837 does help with it. > The second issue is that we are losing the ability to control the path of > the packet and specify which interface the traceroute/ping packet should > arrive on. It is especially useful for packet loss troubleshooting. Would > it be possible to clarify that RFC5837 provided only partical solution? >=20 >=20 > 7) 2.3. Caveats > " >=20 > Hardware dependency:..... > LLAs can > be statically configured such as fe80::1 and fe80::2 which can be > used to configure any required static routing neighborship. This > static configuration is similar in complexity to statically > configured greater than link-local addresses" >=20 > [comment] I'd say that the complexity is higher as such approach > introduces an additional complexity in monitoring/troubleshooting. > Such configuration results in situation when an operator has to deal with > messages like 'BGP neighbor fe80::1%ae1 is down' which might be confusing > and requires additional efforts to identify neighbors. This also applies > to the next paragraph about NMS toolkit: an operator needs to ensure that > NMS and other tools support link-local addresses not just for router > interfaces but for protocol configuration (such as BGP peers etc). >=20 > 8) 2.4. Internet Exchange Points > [comment] It would be great to see two subsection discussing advantages > and caveats like it is done above. >=20 >=20 > Typos found: >=20 > 1) > 1. Introduction > s/OPSF/OSPF/ >=20 > 2) > 2.3. Caveats > s/implementions/implementations/ >=20 >=20 >=20 > -- > SY, Jen Linkova aka Furry