IETF Logo Mail Archive

Re: [Sidrops] New Version Notification for draft-sriram-sidrops-drop-invalid-policy-00.txt

Stephen Kent <stkent@verizon.net> Thu, 15 March 2018 19:03 UTC

Return-Path: <stkent@verizon.net>
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 4976E12EAEC for <sidrops@ietfa.amsl.com>; Thu, 15 Mar 2018 12:03:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable 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 QWNqLVbby7wT for <sidrops@ietfa.amsl.com>; Thu, 15 Mar 2018 12:03:05 -0700 (PDT)
Received: from omr-m015e.mx.aol.com (omr-m015e.mx.aol.com [204.29.186.15]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 400CC12DB6D for <sidrops@ietf.org>; Thu, 15 Mar 2018 12:02:46 -0700 (PDT)
Received: from mtaout-mbc02.mx.aol.com (mtaout-mbc02.mx.aol.com [172.26.221.142]) by omr-m015e.mx.aol.com (Outbound Mail Relay) with ESMTP id 5AF6E38000D2; Thu, 15 Mar 2018 15:02:45 -0400 (EDT)
Received: from iMac-Study.fios-router.home (pool-108-49-30-217.bstnma.fios.verizon.net [108.49.30.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mtaout-mbc02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id AE3D43800032C; Thu, 15 Mar 2018 15:02:44 -0400 (EDT)
To: "Montgomery, Douglas (Fed)" <dougm@nist.gov>, "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>, Tim Bruijnzeels <tim@ripe.net>
Cc: "sidrops-chairs@ietf.org" <sidrops-chairs@ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
References: <152029076512.12908.14537578849320525718.idtracker@ietfa.amsl.com> <BYAPR09MB2773819AB3961189CDA9B4D784D90@BYAPR09MB2773.namprd09.prod.outlook.com> <074D75CB-7D34-4838-BEAA-88AE5E044F6C@ripe.net> <BYAPR09MB27738385E28497E1EC5B32AD84DE0@BYAPR09MB2773.namprd09.prod.outlook.com> <70613650-C8D6-43D9-8643-5694B77BADA9@nist.gov> <5d2afc8e-7f9a-e2bc-fa84-88b943639bd6@verizon.net> <C92B14E7-6F48-4627-8887-776C1321E603@nist.gov> <eb8ed78d-e42f-1ed1-e94f-6821929df9c6@verizon.net> <0A9F6A41-B914-4ED9-989B-DE0736525B2A@nist.gov>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <67d45b24-734a-4043-f910-85fc8c83810e@verizon.net>
Date: Thu, 15 Mar 2018 15:02:44 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <0A9F6A41-B914-4ED9-989B-DE0736525B2A@nist.gov>
Content-Type: multipart/alternative; boundary="------------223FD24F4D80A8BC207EFB41"
Content-Language: en-US
x-aol-global-disposition: G
x-aol-sid: 3039ac1add8e5aaac3543e39
X-AOL-IP: 108.49.30.217
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/-Sw_o-JGNk5GFMa0hrJTH5ZtqV0>
Subject: Re: [Sidrops] New Version Notification for draft-sriram-sidrops-drop-invalid-policy-00.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: Thu, 15 Mar 2018 19:03:09 -0000

Doug, Bob,

Whoops, you're right. 7607 is not applicable to this discussion, as it 
is describing Updates not ROAs. My bad.

Also, Doug, I reluctantly agree that 6483, as an informational RFC, does 
not mandate any behavior. The phrase "by convention" describes the 
suggested ROA length for IPv4 and v6, and suggests that it be used 
exclusively for an address block, with no more specifics. But, as you 
noted, there may be a range of cases in which an INR holder might  use 
an AS 0 ROA and that might cause confusion, absent additional guidance.

RFC 6491 (which is standards track) specifies how IANA planned to use AS 
0 ROAs to mark all reserved and un-allocated  resources as well as some 
types of special purpose resources managed by IANA. It seems to imply 
the processing that it expects of relying parties when these ROAs are 
encountered, but it fails to provide explicit guidance in this respect.

No, I don't recall that the RPKI specifies unique processing for AS 0 ROAs.

Steve
>

v2.23.0 | Report a Bug | By Email