IETF Logo Mail Archive

Re: [Sidrops] trying to limit RP processing variability

Di Ma <madi@rpstir.net> Fri, 10 April 2020 05:09 UTC

Return-Path: <madi@rpstir.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 628DE3A1EE7 for <sidrops@ietfa.amsl.com>; Thu, 9 Apr 2020 22:09:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 o35STA7J8Psi for <sidrops@ietfa.amsl.com>; Thu, 9 Apr 2020 22:09:18 -0700 (PDT)
Received: from out20-97.mail.aliyun.com (out20-97.mail.aliyun.com [115.124.20.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3B83A1EE0 for <sidrops@ietf.org>; Thu, 9 Apr 2020 22:09:16 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.4835023|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_system_inform|0.302309-0.000775527-0.696916; FP=0|0|0|0|0|-1|-1|-1; HT=e02c03300; MF=madi@rpstir.net; NM=1; PH=DS; RN=3; RT=3; SR=0; TI=SMTPD_---.HDzGa1Z_1586495350;
Received: from 192.168.218.230(mailfrom:madi@rpstir.net fp:SMTPD_---.HDzGa1Z_1586495350) by smtp.aliyun-inc.com(10.147.40.2); Fri, 10 Apr 2020 13:09:11 +0800
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Di Ma <madi@rpstir.net>
In-Reply-To: <a0067385-adb8-cadd-3a7f-3a362176d265@verizon.net>
Date: Fri, 10 Apr 2020 13:09:07 +0800
Cc: Robert Kisteleki <robert@ripe.net>, "sidrops@ietf.org" <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B7F02F28-0C7B-4AF6-802E-98A09FE67FD6@rpstir.net>
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net> <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <a0067385-adb8-cadd-3a7f-3a362176d265@verizon.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tZ1oL4NhppItPrM7bCWVgwYSmkw>
Subject: Re: [Sidrops] trying to limit RP processing variability
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
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, 10 Apr 2020 05:09:20 -0000

>> The downside is that this process
>> will not be able to point out the omission. The upside is saves a lot of
>> resources (bandwidth, CPU and all). A further upside is that as a
>> side-effect this protects against a malicious attacker (selectively)
>> hiding objects.
> If the only things that changed in the manifest were the updates and manifest number, then there would be no need to retrieve any additional objects, and with rsync I don't believe there would be any other file retrievals. I can't be sure, but I think thge BBN RPSTIR software behaved that way.  Do we get bonus points?

Yes. 

<On behalf of RPSTIR open source team>

RPSTIR doesn’t retrieve any additional objects by using rsync to keep synchronized with repositories.

However, how to deal with those downloaded objects (use/ignore/warn) depends on how we cope with MFT, CRL and local analysis.

Di

v2.23.0 | Report a Bug | By Email