Re: [sidr] wglc for draft-ietf-sidr-adverse-actions-00

Stephen Kent <kent@bbn.com> Wed, 06 July 2016 17:42 UTC

Return-Path: <kent@bbn.com>
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 B514212D1B7 for <sidr@ietfa.amsl.com>; Wed, 6 Jul 2016 10:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.9
X-Spam-Level:
X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_HOME=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 TfpRzPWIORBV for <sidr@ietfa.amsl.com>; Wed, 6 Jul 2016 10:42:11 -0700 (PDT)
Received: from dfw-mailout2.raytheon.com (dfw-mailout2.raytheon.com [199.46.199.208]) (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 F10FD12D0F9 for <sidr@ietf.org>; Wed, 6 Jul 2016 10:42:10 -0700 (PDT)
Received: from tx-mailout1.directory.ray.com (tx-mailout1.directory.ray.com [147.25.138.100]) by dfw-mailout2.raytheon.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u66Hg8cj022604 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 6 Jul 2016 17:42:09 GMT
Received: from smtp.bbn.com ([128.33.1.81]) by tx-mailout1.directory.ray.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u66Hg7bY011802 (using TLSv1 with cipher DHE-RSA-AES256-SHA(256 bits) verified NO)
Received: from ssh.bbn.com ([192.1.122.15]:40074 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1bKqpq-000L5Y-LQ; Wed, 06 Jul 2016 13:42:06 -0400
To: Randy Bush <randy@psg.com>, Sandra Murphy <sandy@tislabs.com>
References: <8E32FD39-FD20-455C-8BEC-5752DE9C8531@tislabs.com> <m2wpl6ffdp.wl%randy@psg.com> <8196148a-b98d-c680-c714-55498131e7ce@bbn.com> <m28txldluq.wl%randy@psg.com> <F3FB0B9E-A069-4381-9D37-305C4C96A1F8@tislabs.com> <m2furo6kte.wl%randy@psg.com>
From: Stephen Kent <kent@bbn.com>
Message-ID: <93749241-0ef4-8328-7393-cffe3a7846c4@bbn.com>
Date: Wed, 6 Jul 2016 13:42:11 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <m2furo6kte.wl%randy@psg.com>
Content-Type: multipart/alternative; boundary="------------CFB01E6D31A752E95A814316"
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-06_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607060152
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/zTwh-5-3cp8h3pxC-s2HCeE1Wm0>
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] wglc for draft-ietf-sidr-adverse-actions-00
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: Wed, 06 Jul 2016 17:42:13 -0000

Here is the revised text for the relevant part of the intro.

I don't see a need to change the text in the specific attack 
descriptions, given this revised intro text.


    Additionally, when a ROA or router certificate is created that

"competes" with an existing ROA or router certificate (respectively),

the creation of the new ROA or router certificatemay be adverse.

(A newer ROA competes with an older ROA if the newer ROA points to a

different ASN, contains the same or a more specific prefix, and is

issued by a different CA.A newer router certificate competes with

an older router certificate if the newer one contains the same ASN

a different public key, and is issued by a different CA.) Note that

transferring resources, or changing of upstream providers may yield

competing ROAs and/or router certificates, under some circumstances.

Thus not all instances of competition are adverse actions.


Steve