Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs

Eric Osterweil <eosterweil@verisign.com> Mon, 14 November 2011 06:08 UTC

Return-Path: <eosterweil@verisign.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9EE11E820F for <sidr@ietfa.amsl.com>; Sun, 13 Nov 2011 22:08:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.467
X-Spam-Level:
X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227]
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 gbBwstXUDFwg for <sidr@ietfa.amsl.com>; Sun, 13 Nov 2011 22:08:08 -0800 (PST)
Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by ietfa.amsl.com (Postfix) with ESMTP id 91EA911E820B for <sidr@ietf.org>; Sun, 13 Nov 2011 22:08:07 -0800 (PST)
Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKTsCwR5kZKdPk7Go4w/Uoh1xV3MEJkRyy@postini.com; Sun, 13 Nov 2011 22:08:07 PST
Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id pAE686kW017927 for <sidr@ietf.org>; Mon, 14 Nov 2011 01:08:06 -0500
Received: from dul1eosterwe-m1.vcorp.ad.vrsn.com ([10.100.0.69]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Nov 2011 01:08:05 -0500
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1084)
From: Eric Osterweil <eosterweil@verisign.com>
In-Reply-To: <CAL9jLaa+L-C7+Gp54BpM8FjAj+EFMabwQB9SsPW0N4QnFEfVGw@mail.gmail.com>
Date: Mon, 14 Nov 2011 14:08:03 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <E16B2C34-EADC-40B0-8E71-B579A4F7F872@verisign.com>
References: <CAL9jLaa+L-C7+Gp54BpM8FjAj+EFMabwQB9SsPW0N4QnFEfVGw@mail.gmail.com>
To: sidr wg list <sidr@ietf.org>
X-Mailer: Apple Mail (2.1084)
X-OriginalArrivalTime: 14 Nov 2011 06:08:05.0737 (UTC) FILETIME=[C6478590:01CCA293]
Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-reqs
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Nov 2011 06:08:08 -0000

Hey everyone,

So, based on both a long flight, and the comments already made about this draft, I re-read it and wanted to make the following additional comments.  I don't think these are redundant with the comments other have made, but if any of them are, sorry for the noise.

First, I think the notion and general tone of this document are great.  The software engineer in me is very excited to see a good requirements doc at the early stages of a system design.  I hope the remainder of my comments can be read with this high-order bit set. :)

- 3.5 is not a testable requirement.  One cannot be expected to enumerate the space of all things that are _not_ requirements, so why put any in?
- 3.6 ibid
- 3.7 is too vague.  Need to specify where an adversary needs to have access to link-layer.  I have access to the link layer at home, but that doesn't help me insert traffic between any BGP peers. Can I suggest modifying the existing text as follows:
  ``... an enemy who has access to the inter-router link layer...''  the term ``inter-router link'' is borrowed from the cited RFC.
- 3.8 The word ``MAY'' is a very rough fit for the general notion of ``requirements.''  I would suggest it is reworded:
  ``A BGPsec design MUST be able to understand and make use of a security infrastructure (e.g., a PKI) to distribute authenticated data used as input to
         routing decisions when such a resource is available and operators wish to configure it for use.  Such data includes information about
         holdings of address space and ASNs, and assertions about binding of address space to ASNs.''
- 3.9 is also not worded as a requirement.  Does the solution require that a 4k packet even be discussed?  It seems to me that this is not the right document to discuss this.
- 3.10 also does not seem to be a requirement.  It is ``requiring'' an optional exclusion?  I suggest it get yanked.
- 3.11 This also does not seem to be a requirement.  Discussing a design's status in a requirements document is backwards.  I suggest this get yanked.
- 3.19 Seems like it would be hard to test as a requirement.  The problem may be the word ``MAY.''  How could this be made into a testable requirement?
- 3.20 This requirement, again, references a baked design.  This should be restated in a general way.  Suggest,
  ``Any inter-AS use of cryptographic hashes or signatures, should (must?) provide mechanisms for algorithm agility that take the form of...''
- 4.5 The term ``real-time'' seems to carry too many implicit/overloaded meanings.  Could we try to disambiguate with different text.  Maybe we can just drop that term ``real-time'' and leave the rest?
- 4.7 This requirement seems to preach a little bit of a design instead of being agnostic.  Could it be rephrased to be something like:
  ``The output of a router applying BGPsec to a received signed UPDATE MUST be either unequivocal and conform to a fully specified state in the design.''

Thanks,

Eric