Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01

Warren Kumari <warren@kumari.net> Fri, 06 May 2016 19:45 UTC

Return-Path: <warren@kumari.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 B4E8A12D565 for <sidr@ietfa.amsl.com>; Fri, 6 May 2016 12:45:02 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 sQdevPvF9TjE for <sidr@ietfa.amsl.com>; Fri, 6 May 2016 12:45:00 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F6DC12B017 for <sidr@ietf.org>; Fri, 6 May 2016 12:45:00 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id n63so66257003qkf.0 for <sidr@ietf.org>; Fri, 06 May 2016 12:45:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ItL2uuCQsVhzLcDp5fY5fA/1RKqUVzuPxsmOP3bY7Kc=; b=Fl7EKZd7xHUs5mGbRghdQ3O00cwnvsoIvJCd8OPXwp4SHxGsHVE1utAkWq2eOilf2r Yc49B2FU1AtZzJNn+w7KQhG4JobRv6wMdhYF+1rjEbEyjtX3KH282fYP+Sd3lBco/5Sm N69iAJRN+l50HDOhHfQZ9rVhYK/gJnvDRKyYPe6+pWCs5pCRur24mPmn4q7D7yJE+82g MDrGTw5cbq8zGR/jqOmoltINU7wRsZYwVgs8OM2Y5OGuKO4vEIQIACDMlT3qKczP4SDb cEbnSvRnYTTAO/5X8aXwGcL5CU9OiJt3fcEm3Wbg1d30kjcTK1BzapNK8nF5ib6zZG2r lEqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ItL2uuCQsVhzLcDp5fY5fA/1RKqUVzuPxsmOP3bY7Kc=; b=ZzCGudVXlNC0nFjCAIyHZ/AW9ALL9dzffsOenEbuEYddb93hYdCfgK7xClYa5sU3zH GE/kXEZjsWyMqFGc1ycWkPQIyjSEXXKR1c1DSJ/SrHoVkMLJZJRMoljNAwKovazGfBPG k+ApdpCIWAZpZ8STLmikaYsBKDIy7ZD7mG7u/7KFjFlz+bltoRwkF4cO6wD5iplSvi+j 7tsT4Q6XU9XCac3V8DbMYb3Wr+50cMG7sd5Lb2L3h8IERSdZ9LEEUHR9sMQbYvONiK7V oK1iMGCA+srYPz4YiDkj6Jvx4RHIm3li6rZ78ax9j9jPTbACdVsnThwioBqEBBnLP6Io S6TA==
X-Gm-Message-State: AOPr4FWuFJGuNAvUI+5wg8CrRIKSW18PXMLeYs18G7gCCg2Rsb2LP32iQ7uYUahNIJd+S4u4FLdOAQPOov6mrVS+
X-Received: by 10.55.27.215 with SMTP id m84mr2995205qkh.124.1462563899289; Fri, 06 May 2016 12:44:59 -0700 (PDT)
MIME-Version: 1.0
References: <13075573-8AFA-41D7-B0A3-E2B94DF78E61@tislabs.com> <CAL9jLaa6rcJ42cFyJEW1XTcvMfqnLr++VE7kHgpOG1ywL4S1JA@mail.gmail.com> <alpine.WNT.2.00.1605051758070.2308@mw-PC> <CAL9jLaY355-o1yF+whryMNWTJTyET_d082ZTBapE0CtaVdy3Wg@mail.gmail.com> <22b44efa-bd76-0feb-d1ad-2c5b5c3b845c@gmail.com> <CAL9jLabareh=4_nHMUO2GT8kB94J8yRX3HOJCqU6z3P5iOAPbQ@mail.gmail.com>
In-Reply-To: <CAL9jLabareh=4_nHMUO2GT8kB94J8yRX3HOJCqU6z3P5iOAPbQ@mail.gmail.com>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 06 May 2016 19:44:49 +0000
Message-ID: <CAHw9_iJLZ6T5MQYigEiXcDL21dUkiHT2hezpbq1W8ttet8722A@mail.gmail.com>
To: Christopher Morrow <morrowc.lists@gmail.com>, Carlos Martinez <carlos@lacnic.net>
Content-Type: multipart/alternative; boundary="001a11440cf0adea7b053231b138"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/uyOljEKvceaGv5V2wSKYK1PQtC0>
Cc: "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] working group adoption call for draft-kklf-sidr-route-server-rpki-light-01
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 06 May 2016 19:45:03 -0000

On Thu, May 5, 2016 at 10:20 PM Christopher Morrow <morrowc.lists@gmail.com>
wrote:

> On Thu, May 5, 2016 at 5:16 PM, Carlos M. Martinez <carlosm3011@gmail.com>
> wrote:
>
>> hey!
>>
>> On 5/5/16 3:30 PM, Christopher Morrow wrote:
>> >     > I think it's an interesting topic to discuss, I'm a little worried
>> >     > that: "Because the third party said things are 'ok' I'll believe
>> >     > things are ok!"
>> >     >
>> >     > mostly because I don't see a clear method to ensure that 'third
>> party' has:
>> >     >   1) up-to-date information
>> >     >
>> >       Same with RTR cache server.
>> >
>> >
>> > ​except I run the server and can get some data about how updated/etc it
>> > is with respect to collection of roa/etc data.​
>>
>> Not always. In a couple of IXs I know the RTR server is shared and is
>> provided as a service to the IXs members.
>>
>> They trust each other enough to do this, so not trusting the route
>> server would be kind of silly.
>>
>>
> ​sure, but I dont' always use the RS at the IX.​
>
>
... and you don't have to trust the RS if you do.

This feel like a prefect being the enemy of the good type discussion --
 you shouldn't use RS, and you should do your own validation. You should
also always brush your teeth and ear yer veggies -- but, we know some
people will not listen to / follow this advice.
Some people do use route servers, and won't do their own validation - I'd
rather that they have the information available to make a decision than
not...


>
>
>> In any case, you, personally as an individual IX member, are free to
>> have any misgivings about the operational expertise of the IX and you
>> can adjust your BGP configs accordingly (de-prefing whatever you learn
>> from elbonia-ix, ignoring validation state, overwriting communities). I
>> just don't see an argument against what the draft proposes in the
>> scenario you describe.
>>
>


>
>> However, if you dis-trust a particular IX too much, maybe you just
>> should de-peer them. But we disgress :-)
>>
>
> ​yea, so... I didn't REALLY want to rathole the conversation. I'm
> perfectly happy if consenting adults want to do this, that's cool. I may
> not? I may in some places because I can't solve my problem other ways?
>
> I don't think bending things like this is particularly bad, as long as
> people understand what they walked into/on.
>

Yup.
W


>
>
>
>>
>> -Carlos
>>
>> PS: I loved the name Elbonia, Can I license it from you ? :-)
>>
>>
> ​absolutely... Elbonia and Westonia.. they are bad places, (depending on
> your perspective of course.. if you are elbonian, you dislike westonians...
> and vice/versa) :)​
>
>
>
>>
>>
>> _______________________________________________
>> sidr mailing list
>> sidr@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidr
>>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>