IETF Logo Mail Archive

Re: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04

Declan Ma <madi@zdns.cn> Tue, 27 June 2017 11:16 UTC

Return-Path: <madi@zdns.cn>
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 D3E7B1296C9 for <sidr@ietfa.amsl.com>; Tue, 27 Jun 2017 04:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zdns.cn
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 Z88dxTfQZf7F for <sidr@ietfa.amsl.com>; Tue, 27 Jun 2017 04:16:08 -0700 (PDT)
Received: from mail.zdns.cn (smtp.zdns.cn [202.173.10.13]) (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 D10DB1286D6 for <sidr@ietf.org>; Tue, 27 Jun 2017 04:16:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zdns.cn; s=dkim; x=1499166968; i=madi@zdns.cn; h=Content-Type: Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; bh=XWF1kOnsV iPRP/vVKh+gqabMxm0fEY+iNPSnUHCiYtw=; b=VqegbR5IZ8Y+MJ1BM5/CpPdJL G+XG5p5+I0MQx9JyRKbdLfMEiv+udggP/B9XRnrbnirVWzVFdWxMC6wxaMSF7IN5 a2joVDTSgrhOzF5l8tnZ8iz4zGmgZiqOPWuEfB5OgjED21ChCpVvcSj04yJyPr3D OkZs3UFtYTpo7ixJHI=
X-TM-DID: 7b9e397347d80c854e4f54186c401e41
Content-Type: text/plain; charset="gb2312"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Declan Ma <madi@zdns.cn>
In-Reply-To: <184B0473-C763-495C-92F2-8C93B303E4B5@ripe.net>
Date: Tue, 27 Jun 2017 19:15:40 +0800
Cc: Mehmet Adalier <madalier@antarateknik.com>, sidr <sidr@ietf.org>, sidr chairs <sidr-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1926242A-6DE6-457D-97F3-C012613F720E@zdns.cn>
References: <801A5228-4DF6-4882-A2A9-77B9BAD58871@tislabs.com> <FE73D619-1368-4A22-8FB1-D310F277D731@ripe.net> <CAL9jLaYv-RZz8rzDy9XpjAsuVV4tFtxO33-0OjLQo2J00R60GA@mail.gmail.com> <87ACB275-5A80-427B-A6D6-D888CC72E03C@tislabs.com> <5D93CE9B-B802-4014-A3B8-F8B3A2F42456@antarateknik.com> <9ACE1099-C5F3-48A3-BE97-649BDA8123BC@zdns.cn> <184B0473-C763-495C-92F2-8C93B303E4B5@ripe.net>
To: Tim Bruijnzeels <tim@ripe.net>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/St3Sp_WwxFjacnSpf9m2hXxZh7E>
Subject: Re: [sidr] once more with feeling! WGLC for draft-ietf-sidr-slurm-04
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 27 Jun 2017 11:16:11 -0000

> 在 2017年6月27日，19:04，Tim Bruijnzeels <tim@ripe.net> 写道：
> 
> 
>> On 27 Jun 2017, at 06:19, Declan Ma <madi@zdns.cn> wrote:
>> 
>>> 2)  Regarding keys, “only in combination with an asserted ASN for that key,” not on the key alone
>> 
>> 
>> I think it’s reasonable to make it obliged to do filtering on the SKI in combination with an asserted ASN. 
>> 
>> We authors will be figuring out how to get this done after WGLC.
> 
> Or.. should we only allow filtering on asserted ASN? Is there a good use case for saying: “I know *this* key is bad for *this* ASN, but I am willing to accept assertions by this same ASN for other keys?”

There is a use case.

An ASN holder authorized more than one routers to do BGP announcements. Yet the peering ISP just wants to ignore one of the routers, with other authorized routers remaining unaffected.


> 
> I kind of suspect that if you don’t trust one of the assertions made by the ASN (for whatever reason), you probably don’t want to trust any of their assertions.

It has nothing to do with the trust on ASN. I believe we should keep this as a chance for local control.

Di

v2.23.0 | Report a Bug | By Email