IETF Logo Mail Archive

Re: [Sidr] Rsync

Geoff Huston <gih@apnic.net> Tue, 18 March 2008 22:02 UTC

Return-Path: <sidr-bounces@ietf.org>
X-Original-To: ietfarch-sidr-archive@core3.amsl.com
Delivered-To: ietfarch-sidr-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 504853A6FB0; Tue, 18 Mar 2008 15:02:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.643
X-Spam-Level:
X-Spam-Status: No, score=-100.643 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wR1m5ufvRDTh; Tue, 18 Mar 2008 15:02:51 -0700 (PDT)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D89A3A6F9C; Tue, 18 Mar 2008 15:02:46 -0700 (PDT)
X-Original-To: sidr@core3.amsl.com
Delivered-To: sidr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C6233A6F9C for <sidr@core3.amsl.com>; Tue, 18 Mar 2008 15:02:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d272xt6bxH7K for <sidr@core3.amsl.com>; Tue, 18 Mar 2008 15:02:41 -0700 (PDT)
Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id A73893A6A56 for <sidr@ietf.org>; Tue, 18 Mar 2008 15:02:38 -0700 (PDT)
Received: from dhcp6.potaroo.net (dhcp6.potaroo.net [203.10.60.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 1281CD5F2D; Wed, 19 Mar 2008 08:00:19 +1000 (EST)
Message-ID: <47E03B72.3040301@apnic.net>
Date: Wed, 19 Mar 2008 09:00:18 +1100
From: Geoff Huston <gih@apnic.net>
User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213)
MIME-Version: 1.0
To: Sandra Murphy <sandy@sparta.com>
References: <mailman.17.1205434814.25117.sidr@ietf.org><4D22EF37-FCF2-48BB-889F-8FE8C1 7A1B04@aepnetworks.com> <47DE5161.3030104@ripe.net> <004201c88855$c77f8540$6e00a8c0@ad.redback.com> <47DF04FB.9020103@apnic.net> <p06240503c40591103fc4@[128.89.89.71]> <Pine.WNT.4.64.0803181319130.928@SANDYM-LT.columbia.ads.sparta.com>
In-Reply-To: <Pine.WNT.4.64.0803181319130.928@SANDYM-LT.columbia.ads.sparta.com>
Cc: "'Michele (Mike) Hjorleifsson'" <mikeh@aepnetworks.com>, sidr@ietf.org
Subject: Re: [Sidr] Rsync
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sidr-bounces@ietf.org
Errors-To: sidr-bounces@ietf.org

> On Tue, 18 Mar 2008, Stephen Kent wrote:
> 
>> At 9:55 AM +1000 3/18/08, Robert Loomans wrote:
> <snip>
>> It has been suggested that access to repositories might be
>> TLS-protected, even though the data is intended to be widely
>> available.  The motivation is that requiring a TLS credential (issued
>> under the RPKI) could be used to reject DoS attacks by complete
>> outsiders.
> 


Perhaps the clarifying question is: are you talking about read access or write access?

The comments I've seen that support the notion of no need for TLS support appear to refer to read access, where anyone can be a relying party and the combination of manifests and digital signatures on retrieved objects is sufficient to ensure that the relying party can determine the completeness and validity of the retrieved information.

The comments I've seen in favour of TLS appear to refer to write access where a CA or EE has outsouced the publication repository management function to a third party and there may be some need for a secured channel of write access as a means of DOS protection.

The drafts on this topic (draft-huston-sidr-repos-struct-01.txt, and draft-ietf-sidr-res-certs-09.txt) refer only to read access.



_______________________________________________
Sidr mailing list
Sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

v2.23.0 | Report a Bug | By Email