Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?

Christopher Morrow <morrowc.lists@gmail.com> Fri, 08 April 2011 17:53 UTC

Return-Path: <christopher.morrow@gmail.com>
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 E3F403A69EF for <sidr@core3.amsl.com>; Fri, 8 Apr 2011 10:53:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.395
X-Spam-Level:
X-Spam-Status: No, score=-103.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 I8ZA5uzCyMjq for <sidr@core3.amsl.com>; Fri, 8 Apr 2011 10:53:20 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 19C633A69D6 for <sidr@ietf.org>; Fri, 8 Apr 2011 10:53:19 -0700 (PDT)
Received: by wwa36 with SMTP id 36so3193141wwa.13 for <sidr@ietf.org>; Fri, 08 Apr 2011 10:55:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=EIgWCaePULeIr5YVR4ccyP/lPhe/EiWw2gyIT6fGYC4=; b=SxiUN72KVHoDxZnZKelYPOI0W2PbW1m0rPMswieqnKrYP4p1g4kjgP6uya83I18zgx ZatnSLp4rZW2z+dxUjtDtWOxfocbJiFoLBRvNgLPfzNt39KMNbGrPpU9te5i0hbUksqr S3Y5c27ojODDvYKTojqZw7KMFrLaOVCcyc3cg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=H7UtxLAsdP6cke48Jw7lsJmQxuoK+eZfzvH76RKORg2PCutZJXdMqAffz7/ird4qDz 09Oun2i9yzuSPJ6h9NnOO0Uw1Esua9CGHvzUD5/SJaczafg6eGJhoNo/E2vct+8Zidsb apPVFVM64w+oZPZFBgwKZ5sIwastjnWnWndW0=
MIME-Version: 1.0
Received: by 10.216.167.65 with SMTP id h43mr6680wel.17.1302285304831; Fri, 08 Apr 2011 10:55:04 -0700 (PDT)
Sender: christopher.morrow@gmail.com
Received: by 10.216.13.131 with HTTP; Fri, 8 Apr 2011 10:55:04 -0700 (PDT)
In-Reply-To: <4A88F7EC-12D4-4AAA-92BE-D6A8BEACF776@cisco.com>
References: <BANLkTi=eZ=pQ2gJfiPBfeb4frH8Tncempw@mail.gmail.com> <m21v1i9ha8.wl%randy@psg.com> <BF88D659-1BE5-4DD2-AB24-7A113360DF37@cisco.com> <m2tyea7urr.wl%randy@psg.com> <8BE1C346-6214-4343-9E46-BFA8D96E4B6C@cisco.com> <BANLkTikTqCD4_=-Sjs7ng2qSLn3vYw5qLw@mail.gmail.com> <55B61488-045C-44FA-90DB-83543A6209FB@cisco.com> <m2ipupsmuy.wl%randy@psg.com> <BANLkTinoJRu=hkoiCS=Xj000r3W+n5KnZQ@mail.gmail.com> <F05F2600-9E6C-410B-9EC5-F4245E6F5B88@cisco.com> <20110408170400.GC11350@juniper.net> <4A88F7EC-12D4-4AAA-92BE-D6A8BEACF776@cisco.com>
Date: Fri, 08 Apr 2011 13:55:04 -0400
X-Google-Sender-Auth: 5zCQNAhOylSKqt1ATmEuO3MpUwU
Message-ID: <BANLkTiknwZajL9CKbdA3xfrXjqQL-kCOmQ@mail.gmail.com>
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Pradosh Mohapatra <pmohapat@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] WGLC draft-sidr-rpki-rtr - take 2?
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/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: Fri, 08 Apr 2011 17:53:21 -0000

On Fri, Apr 8, 2011 at 1:49 PM, Pradosh Mohapatra <pmohapat@cisco.com> wrote:
>> not sure if mandating a single transport is needed at all.
>>
>> since the pros and cons of the various transport protocols
>> (TCP, TCP-MD5, TCP-AO, IPSec, SSH) are well understood, why not simply
>> enumerating the choices and leave it to the operator's local security policy
>> which one to deploy ?
>>
>> IMO you cannot dictate local security policy as they are different between
>> operators. also if the level of containment is sufficiently enough (e.g.
>> local-cache only reachable through vrf, not accessible through internet
>> it is perfectly reasonable even to load your cache records using vanilla TCP.)
>
> I have no problem listing various transports. I thought there was a suggestion to
> keep one of them mandatory to encourage better interoperability. That makes
> some sense.

I believe, and Randy/authors can jump in here, the point of a MUST was
to ensure we had one (at least) transport across all parts of the
system. (interoperability, yes).

How about authors/hannes/pradosh work out their best guess and we go
from there? say by monday? :)

-Chris