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

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Sat, 07 October 2017 00:41 UTC

Return-Path: <jheitz@cisco.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 91ECC13207A for <sidrops@ietfa.amsl.com>; Fri, 6 Oct 2017 17:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level:
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 d47sbZWILejG for <sidrops@ietfa.amsl.com>; Fri, 6 Oct 2017 17:41:07 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC5213331E for <sidrops@ietf.org>; Fri, 6 Oct 2017 17:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1943; q=dns/txt; s=iport; t=1507336867; x=1508546467; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=0nRng+5egPFlmeMbszZrIQCaLxnN+DRvIO5OVfkTL18=; b=mILEkQ3EN335Wi4iIVoWzhE1xyvzIapYuo0ITwfxNX21Xx1jYcq//0v1 rcvYjwY+1H7ddSqf4U8nXkNhs2+CVk+vvIIHoskUhK4kby2ZArqsDmLWi Iv0diADPvco0p3qak0wd3hvJ6Ybi2Ri4kZHMSRtCdj8HF8Cg6nMwdiCE+ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CfAAA7IthZ/4MNJK1cGQEBAQEBAQEBAQEBBwEBAQEBg12BUicHjhKPbYF2li+CEgqFOwKEID8YAQIBAQEBAQEBayiFGAEBAQECATo/BQcEAgEIEQQBAR8JBzIUCQgCBA4FCIogCKdpizgBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgy2CAoFRgWqDKYp4BaEzApRakxOIToxeAhEZAYE4AR84gQ54FYdmdoZ8LIEFgRABAQE
X-IronPort-AV: E=Sophos;i="5.42,486,1500940800"; d="scan'208";a="13742301"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Oct 2017 00:41:06 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v970f5v7024203 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 7 Oct 2017 00:41:06 GMT
Received: from xch-aln-014.cisco.com (173.36.7.24) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 6 Oct 2017 19:41:05 -0500
Received: from xch-aln-014.cisco.com ([173.36.7.24]) by XCH-ALN-014.cisco.com ([173.36.7.24]) with mapi id 15.00.1320.000; Fri, 6 Oct 2017 19:41:05 -0500
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: Randy Bush <randy@psg.com>
CC: SIDR Operations WG <sidrops@ietf.org>
Thread-Topic: [Sidrops] draft-ymbk-sidrops-ov-clarify-01.txt
Thread-Index: AQHTCM8o/uckWQovpkasQZS9cIJoI6LX4zDQgABb5QD//7PrEA==
Date: Sat, 07 Oct 2017 00:41:05 +0000
Message-ID: <4bb0679ec1284441a50d9a0ebb48e070@XCH-ALN-014.cisco.com>
References: <m2k22qzqm7.wl-randy@psg.com> <50b3ef1b548d4726a5628d5edf53cf2d@XCH-ALN-014.cisco.com> <m2h8vbn87h.wl-randy@psg.com>
In-Reply-To: <m2h8vbn87h.wl-randy@psg.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.131.69]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/ghnE3kUNFJeCRpCgwIwUbaI8R8Y>
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: Sat, 07 Oct 2017 00:41:08 -0000

Randy,

0 helps if an AS is not announcing its prefix in BGP.
Registering it under AS0 causes the evil announcement to be invalid.
The evil announcer cannot prepend 0.
Of course, it should register under AS0 only, not under its own ASN.

RPKI is actually really good at protecting unannounced prefixes.
It can protect announced prefixes if you can manage to get a
shorter AS_PATH length than the evil prepended path.

Thanks,
Jakob


-----Original Message-----
From: Randy Bush [mailto:randy@psg.com] 
Sent: Friday, October 6, 2017 4:54 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: SIDR Operations WG <sidrops@ietf.org>
Subject: Re: [Sidrops] draft-ymbk-sidrops-ov-clarify-01.txt

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.