Re: [Gen-art] Gen-ART LC review of draft-ietf-opsec-lla-only-07

Jari Arkko <jari.arkko@piuha.net> Thu, 21 August 2014 14:34 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C091A6F0B; Thu, 21 Aug 2014 07:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.955
X-Spam-Level:
X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] 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 y9Yoh4OkHkC1; Thu, 21 Aug 2014 07:34:01 -0700 (PDT)
Received: from p130.piuha.net (unknown [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 819AD1A8749; Thu, 21 Aug 2014 07:34:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 750322CED5; Thu, 21 Aug 2014 17:33:59 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAf3CV5vIAss; Thu, 21 Aug 2014 17:33:55 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 8F5502CED4; Thu, 21 Aug 2014 17:33:55 +0300 (EEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_4E0A4A8B-D858-4A6B-8CAD-C08D472EF709"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <0AC232F9-A8E7-4632-BC67-682813152C70@piuha.net>
Date: Thu, 21 Aug 2014 17:33:53 +0300
Message-Id: <EF83FD4C-572F-485F-BE6A-BC5D9C1659F8@piuha.net>
References: <012001cf52f7$f0361670$d0a24350$@akayla.com> <0AC232F9-A8E7-4632-BC67-682813152C70@piuha.net>
To: Peter Yee <peter@akayla.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/hLAEASxE9MiL0hy2j-BTwq9cBfU
Cc: draft-ietf-opsec-lla-only.all@tools.ietf.org, Gen Art <gen-art@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [Gen-art] Gen-ART LC review of draft-ietf-opsec-lla-only-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 14:34:02 -0000

Responding to myself… compared -07 to -10. It seems that some of your points have been taken into account. I still think the SSH example is a bit weak, as you pointed out…

Jari

On 20 Aug 2014, at 10:19, Jari Arkko <jari.arkko@piuha.net> wrote:

> Hi,
> 
> I’m wondering which of the below issues have been corrected in the most recent version of the draft. Have the authors seen the review? Some of the comments at least have been taken into account, so the answer is probably yes.
> 
> But I do not see e-mails from the authors on this topic in my Inbox, so I want to check.
> 
> Jari
> 
> On 08 Apr 2014, at 09:58, Peter Yee <peter@akayla.com> wrote:
> 
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>> 
>> Please resolve these comments along with any other Last Call comments you
>> may receive.
>> 
>> Document: draft-ietf-opsec-lla-only-07
>> Reviewer: Peter Yee
>> Review Date: April-7-2014
>> IETF LC End Date: April-7-2014
>> IESG Telechat date: TBD
>> 
>> Summary: This draft is basically ready for publication as an Informational
>> RFC, but has issues that should be fixed before publication. [Ready with
>> issues.]
>> 
>> This document discusses the (controversial) use of IPv6 link-local addresses
>> on router infrastructure links.  I don't find all of the arguments for use
>> of link-local addresses to be terribly compelling, but I'm not utterly
>> averse to the document's publication as a summary of some of the pros and
>> cons for those who desire to configure their routers in the manner
>> prescribed.  There may be other reasons that should be taken into
>> consideration, but I lack a network operator's experience to discuss them.
>> 
>> Minor:
>> 
>> Page 4, 4th paragraph: I don't buy this argument.  DNS can be simplified for
>> non-link-local addresses by simply not registering those addresses in DNS.
>> Use of link-local addresses isn't a requirement to simplify DNS.
>> 
>> Page 4, 5th paragraph, 2nd sentence: SSH brute force password attacks aren't
>> really reduced unless the reduction is simply not being able to attack a
>> single router over multiple interfaces in parallel.  A better scheme for
>> reducing SSH brute force password attacks might be to limit the rate of
>> responses to SSH login attempts in the face of repeated failures.
>> Considering dropping this marginal example.
>> 
>> Page 4, 6th paragraph, 1st sentence: I'm not sure what is meant by "the same
>> result".  Is this in reference to all 5 paragraphs that precede the 6th?  If
>> so, you might wish to elaborate with "the same results as the above" .
>> However, if the same results can be obtained without going to link-local
>> addressing as this paragraph indicates, why is the use of link-local
>> addressing being suggested?  The paragraph might do well to explain why one
>> scheme is preferable over the other.
>> 
>> Page 6, 1st partial paragraph: the argument is made that "more work" is
>> required to discover all of an IXPs loopback interface addresses before a
>> generic attack can be mounted.  This wouldn't seem to be a lot of upfront
>> work and once it has been done, the advantage is negated.  I don't find the
>> argument particularly persuasive.  
>> 
>> Nits:
>> 
>> Page 2, Section 2 title: change "Address" to "Addressing".
>> 
>> Page 3, second paragraph: change "non link-local" to "non-link-local".
>> 
>> Page 4, 1st paragraph, 3rd sentence: change "accellerated" to "
>> accelerated".
>> 
>> Page 4, 5th paragraph, 2nd sentence: delete the comma after "[RFC4987])" and
>> change the "or" to "and".
>> 
>> Page 6, 1st full paragraph, 1st sentence: change "allow" to "allows" and
>> insert "an" before "MPLS LSP".
>> 
>> 
>> 		-Peter Yee
>> 
>> 
>> 
>> _______________________________________________
>> Gen-art mailing list
>> Gen-art@ietf.org
>> https://www.ietf.org/mailman/listinfo/gen-art
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art