Re: [Sidrops] draft-ymbk-sidrops-ov-clarify-01.txt

Randy Bush <randy@psg.com> Fri, 06 October 2017 23:54 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516581330B1 for <sidrops@ietfa.amsl.com>; Fri, 6 Oct 2017 16:54:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, 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 dRbKEL5w4sQj for <sidrops@ietfa.amsl.com>; Fri, 6 Oct 2017 16:54:29 -0700 (PDT)
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 CE6421321A7 for <sidrops@ietf.org>; Fri, 6 Oct 2017 16:54:29 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1e0cRo-0006Vj-BB; Fri, 06 Oct 2017 23:54:28 +0000
Date: Sat, 07 Oct 2017 08:54:26 +0900
Message-ID: <m2h8vbn87h.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Jakob Heitz <jheitz@cisco.com>
Cc: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <50b3ef1b548d4726a5628d5edf53cf2d@XCH-ALN-014.cisco.com>
References: <m2k22qzqm7.wl-randy@psg.com> <50b3ef1b548d4726a5628d5edf53cf2d@XCH-ALN-014.cisco.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.2 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/sidrops/No6y2_DKgVczg70_Fp1kA9ukn_I>
Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-clarify-01.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Oct 2017 23:54:31 -0000

hi jakob,

> ROAs and BGP announcements
> 
> Every IP prefix that is matched by a ROA SHOULD be announced to BGP by
> the AS stated in the ROA unless that AS is AS 0. If the owner AS does
> not announce the prefix, then another AS can announce the prefix and
> simply prepend the owner ASN. Such a false announcement will pass RPKI
> validation. Also, there will be no legitimate announcement to compete
> with it.  If an AS wishes to protect an IP address prefix without
> announcing it, then it SHOULD issue a ROA that associates the prefix
> with AS 0.

unless i am not reading this as you intended, this is not about how
validation is done, but is directed at operational practice, rfc 7115.
the draft under discussion is about how validation is done.

it should be clear from 7115 that OV is forgable as you describe; an
attacker can prepend the expected origin.  and, as validation just has
to match *any* roa, as 0 does not help [0].  to strongly authenticate
origination, you need to go to bgpsec.

randy

--

0 - as far as i remember, as 0 has no special properties other than
    being an as number which is not allowed to appear in bgp, see
    rfc 7607, but is allowed to appear in a roa.