IETF Logo Mail Archive

Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10

Randy Bush <randy@psg.com> Fri, 09 December 2016 21:57 UTC

Return-Path: <randy@psg.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 1DA391296A8 for <sidr@ietfa.amsl.com>; Fri, 9 Dec 2016 13:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.797
X-Spam-Level:
X-Spam-Status: No, score=-9.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 MIzeeKN-HEgc for <sidr@ietfa.amsl.com>; Fri, 9 Dec 2016 13:57:14 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4268129593 for <sidr@ietf.org>; Fri, 9 Dec 2016 13:57:14 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1cFTAF-0001uL-Vf; Fri, 09 Dec 2016 21:57:12 +0000
Date: Fri, 09 Dec 2016 13:57:11 -0800
Message-ID: <m2mvg44vgo.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
In-Reply-To: <626EE1F7-878E-453A-A33B-DAAC21907261@cisco.com>
References: <1FBAD3F8-5387-47A3-9988-A49A3133490A@cisco.com> <m2d1ha2ul2.wl-randy@psg.com> <C7A005B5-7550-4B74-8C80-C32C60093CD9@cisco.com> <m21sxkwozs.wl-randy@psg.com> <m2y3zra1ns.wl-randy@psg.com> <626EE1F7-878E-453A-A33B-DAAC21907261@cisco.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/8MZcfYNNgkL8_xOXiYRWwsdI-38>
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] AD Review of draft-ietf-sidr-bgpsec-ops-10
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 09 Dec 2016 21:57:16 -0000

> Yes, there should be something about private ASNs in the protocol spec.
> 
> It would be nice to also see some operational guidance in this document.
> 
> Alvaro.
> 
> otoh, private AS numbers are used in non-confed topologies, e.g. the bgp
> stub customer who uses a private AS.  they should not sign of course.
> but once i receive their announcement and strip the private AS,
> can/should i sign?  i just looked at bgpsec-protocol and found no
> guidance.

first the protocol spec needs to make clear if the real AS can proxy
sign for a connected private AS.  then i can hack the ops doc.

seems to me that, as the real AS is required to strip the private AS
from the path, the real AS should be able to proxy sign.  but then
who has the cert to create the roa, etc.?

randy

v2.23.0 | Report a Bug | By Email