Re: [sidr] I-D Action: draft-ietf-sidr-publication-02.txt

Tim Bruijnzeels <tim@ripe.net> Mon, 02 April 2012 14:41 UTC

Return-Path: <tim@ripe.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD79021F84D1; Mon, 2 Apr 2012 07:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cscTQwQFmdr; Mon, 2 Apr 2012 07:41:36 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD5121F84CF; Mon, 2 Apr 2012 07:41:27 -0700 (PDT)
Received: from ayeaye.ripe.net ([193.0.23.5]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SEiRf-0003bx-70; Mon, 02 Apr 2012 16:41:24 +0200
Received: from timbru.vpn.ripe.net ([193.0.21.62]) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <tim@ripe.net>) id 1SEiRf-0007dv-1q; Mon, 02 Apr 2012 16:41:23 +0200
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Tim Bruijnzeels <tim@ripe.net>
In-Reply-To: <20120329092910.150E66EDFC8@minas-ithil.hactrn.net>
Date: Mon, 02 Apr 2012 16:41:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D1F81DC-1B22-4362-BBBC-A6E2DC80C7C1@ripe.net>
References: <20120312205331.1904.65803.idtracker@ietfa.amsl.com> <CAL9jLaZ9=L0oZjThygnd-2D7naOetcrKPJ45-5ToUNYcRUCkiA@mail.gmail.com> <20120329092910.150E66EDFC8@minas-ithil.hactrn.net>
To: Rob Austein <sra@hactrn.net>
X-Mailer: Apple Mail (2.1084)
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a071939087299476dd9cbd1ee307fefef1b7a
Cc: sidr@ietf.org, sidr-chairs@ietf.org, Samuel Weiler <weiler@watson.org>
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-publication-02.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Mon, 02 Apr 2012 14:41:37 -0000

Hi,

On 29 Mar 2012, at 11:29, Rob Austein wrote:

> At Wed, 28 Mar 2012 08:57:19 -0400, Christopher Morrow wrote:
>> 
>> Draft Author Ship Steerers,
>> This we didn't chat about at the meeting(s), but are there outstanding
>> bits/pieces or should this be sent along for WGLC in the near future?
> 
> Not ready yet.  A few year's experience of using this protocol
> suggests the need for an additional message type, to let the RPKI
> engine monitor what the publication server has on file for it.  We've
> seen a few cases where, for whatever reason (bug, system crash, ...)
> the two can get out of sync, and while it's theoretically possible for
> the RPKI engine to determine what's in the publication repository by
> fetching as if it were a relying party, it'd probably be easier just
> to let the RPKI engine ask the publication server directly.

All this sounds very reasonable.

Furthermore I expect that the current discussion on rpki retrieval can have implications for this protocol as well. For example, if it is decided that consistent delta sets should be supported (as I argued for in another thread), then I think we will need some transaction logic in this protocol: BEGIN, publish, publish, withdraw ... COMMIT (i.e. begin and commit pdus, or probably better: one big pdu containing all updates, instead of sending the publish and withdraw pdus separately).

Tim