Re: [RPSEC] Last Call for draft-ietf-rpsec-bgpsecrec-09
Joe Touch <touch@ISI.EDU> Tue, 11 March 2008 11:42 UTC
Return-Path: <rpsec-bounces@ietf.org>
X-Original-To: ietfarch-rpsec-archive@core3.amsl.com
Delivered-To: ietfarch-rpsec-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715873A6DA8; Tue, 11 Mar 2008 04:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.64
X-Spam-Level:
X-Spam-Status: No, score=-100.64 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GzDkbuQWAGs; Tue, 11 Mar 2008 04:42:24 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A56A28C3B1; Tue, 11 Mar 2008 04:42:24 -0700 (PDT)
X-Original-To: rpsec@core3.amsl.com
Delivered-To: rpsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44B13A6C6A for <rpsec@core3.amsl.com>; Tue, 11 Mar 2008 04:42:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVOXP3ShLhUJ for <rpsec@core3.amsl.com>; Tue, 11 Mar 2008 04:42:22 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id A8E6F3A688F for <rpsec@ietf.org>; Tue, 11 Mar 2008 04:42:22 -0700 (PDT)
Received: from [127.0.0.1] ([63.133.180.130]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id m2BBcT5N001654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Mar 2008 04:38:30 -0700 (PDT)
Message-ID: <47D66F00.3090903@isi.edu>
Date: Tue, 11 Mar 2008 04:37:36 -0700
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: Russ White <riw@cisco.com>
References: <47C414C3.7010408@cisco.com>
In-Reply-To: <47C414C3.7010408@cisco.com>
X-Enigmail-Version: 0.95.6
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: rpsec@ietf.org
Subject: Re: [RPSEC] Last Call for draft-ietf-rpsec-bgpsecrec-09
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/rpsec>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0272817021=="
Sender: rpsec-bounces@ietf.org
Errors-To: rpsec-bounces@ietf.org
Russ White wrote:
> Y'all:
>
> I'd like to start the two week last call window for
> draft-ietf-rpsec-bgpsecrec-09.
IMO, the document needs to be more clear about the layers at which
security is being described. The abstract makes a specific assertion
about scope (direct manipulation of BGP and information contained
within), but the doc repeatedly exceeds that scope by discussing issues
of TCP integrity. The ONLY exception to this is the kind of "binding"
issue of taking advantage of associations in IPsec or TCP/MD5 (and its
potential successors) in pinning BGP. Issues of network or transport
layer protection are out of scope, and need to be removed.
Specific suggestions:
Abstract - would benefit from explicitly stating whether this ifocuses
net, transport, or routing layer requirements. It appears to focus on
routing (as per the "Attacks that do not..." assertion), but this needs
to be carried throughout the document.
Abstract - If "attacks that do not involve direct manipulation of BGP,
and the information contained within BGP, are outside the scope of this
document", then the mention of TCP issues are outside the scope of this
document.
MUST/MAY/SHOULD - it's not clear that such terms should be used in an
Informational document, IMO.
sec 3., first bullet on peer comm: I disagree that TCP integrity is
relevant, if the assertion in the abstract about scope is accurate.
sec 11., the note about linked authentication is important - and should
be carried down to the network layer potentially. However, this section
should be retitled "linked protection layers"; it is not really about
transport security. The sentence about transport security requirements
('a detaileed treatment') should be moved to the intro, where the scope
of the doc should be reinforced, and should include pointers to
Bellovin's doc and TCP-Auth-Opt, IMO.
sec 12. since transport is out of scope, it's not clear why TCP-MD5 key
management shortcomings are relevant; this first sentence can be omitted
without loss of impact.
_______________________________________________ RPSEC mailing list RPSEC@ietf.org https://www.ietf.org/mailman/listinfo/rpsec