Re: [RPSEC] BGP Security Requirements v08

Tony Tauber <ttauber@1-4-5.net> Tue, 10 July 2007 21:36 UTC

Return-path: <rpsec-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8NNI-0001V1-S3; Tue, 10 Jul 2007 17:36:01 -0400
Received: from rpsec by megatron.ietf.org with local (Exim 4.43) id 1I8NNF-0001Uv-UE for rpsec-confirm+ok@megatron.ietf.org; Tue, 10 Jul 2007 17:35:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8NNF-0001Um-KK for rpsec@ietf.org; Tue, 10 Jul 2007 17:35:57 -0400
Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8NNB-0004mn-6g for rpsec@ietf.org; Tue, 10 Jul 2007 17:35:57 -0400
Received: from m106.maoz.com (localhost [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8/Debian-2) with ESMTP id l6ALZcOj014580; Tue, 10 Jul 2007 14:35:38 -0700
Received: (from ttauber@localhost) by m106.maoz.com (8.14.0/8.13.8/Submit) id l6ALZcgs014579; Tue, 10 Jul 2007 14:35:38 -0700
Date: Tue, 10 Jul 2007 14:35:38 -0700
From: Tony Tauber <ttauber@1-4-5.net>
To: Stephen Kent <kent@bbn.com>
Subject: Re: [RPSEC] BGP Security Requirements v08
Message-ID: <20070710213538.GB27477@1-4-5.net>
References: <20070709142132.GF7635@1-4-5.net> <p06240505c2b95577827e@[128.89.89.71]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <p06240505c2b95577827e@[128.89.89.71]>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: rpsec@ietf.org
X-BeenThere: rpsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing Protocol Security Requirements <rpsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/rpsec>
List-Post: <mailto:rpsec@ietf.org>
List-Help: <mailto:rpsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rpsec>, <mailto:rpsec-request@ietf.org?subject=subscribe>
Errors-To: rpsec-bounces@ietf.org

Hi Steve,

As usual your detailed comments were helpful.
Comments are inline.

On Tue, Jul 10, 2007 at 11:38:44AM -0400, Stephen Kent wrote:
> Tony,
> 
> Thanks for updating the requirements document. I see that almost all
> of my suggested edits were incorporated, but a couple of questions I 
> raised in my comments were not addressed, which leaves some 
> ambiguity.  Here are the residual questions/comments:
>
> In (new) section 4.2 (Incremental Deployment), the second bullet says:
> 
> o  A BGP security mechanism MUST provide backward compatibility in 
> the message formatting, transmission, and processing of routing
> information carried through a mixed security environment.  Message
> formatting in a fully secured environment MAY be handled in a
> non-backward compatible fashion though care must be taken to ensure
> UPDATES can traverse intermediate routers which don't support the new
> format.
> 
> My comment was:  One might interpret this to mean that any extended 
> form of UDATE message MUST be transmitted through ASes that are not
> capable of processing it. This is imposing an unnecessary burden on
> solutions, since an alternative is to just mot send such messages
> through ASes than can't make use of them.

I see this requirement as a (possibly unnecessary) corollary to the
requirement for supporting non-contiguous deployments.  The fact that
the interpretation is ambiguous about how specifically one achieves this
goal (perhaps properly) reflects the fact that solutions can get
creative.  

I'd like to hear whether others find this item problematic.

> I'd like to see a clarification of the intent of this bullet, 
> relative to the concern I raised in my comment.
> 
> The next bullet in the section says:
> 
> In an environment where both secured and non-secured systems are 
> interoperating a mechanism MUST exist for secured systems to identify 
> whether an originator intended the information to be secured.
> 
> My questions was: Does this refer to the Origin AS or the neighbor AS?
> 
> I still think we need to say to which originator this bullet refers.

My reading of it would be "originator".  I didn't find it ambiguous.

Perhaps you or someone else could suggest clearer text if needed.

> Finally, the last paragraph of (new) section 8 says:
> 
> An associated delegation criteria is the requirement to allow for 
> non-BGP stub networks.  As a result, all secured BGP implementations 
> MUST allow for the contemporaneous origination of a route for a 
> prefix by more than one AS.
> 
> I had suggested adding the phrase "subject to the authorization 
> criteria above." at the end of the last sentence. I was wondering why 
> you chose to not add this?

It was a simple oversight.  I can put it in.

Thanks,

Tony


_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec