From nobody Tue Sep 1 06:54:44 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A42E1B3F44 for ; Tue, 1 Sep 2015 06:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dQ5Ervk-ZHEQ for ; Tue, 1 Sep 2015 06:54:41 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81C671B465A for ; Tue, 1 Sep 2015 06:54:41 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id CABEC28B0052; Tue, 1 Sep 2015 09:54:40 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id B00631F8035; Tue, 1 Sep 2015 09:54:40 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) Content-Type: multipart/signed; boundary="Apple-Mail=_24BAB446-0D35-4EB7-8F04-8B07E074C64D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Sandra Murphy In-Reply-To: Date: Tue, 1 Sep 2015 09:54:24 -0400 Message-Id: <431E35D5-42E8-4A93-A763-112872753600@tislabs.com> References: <25C98F11-9273-4B80-8B3A-FB486166E21D@tislabs.com> To: Randy Bush X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr wg list , Sandra Murphy Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 13:54:43 -0000 --Apple-Mail=_24BAB446-0D35-4EB7-8F04-8B07E074C64D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Speaking as a regular ol=92 member On Aug 27, 2015, at 5:02 PM, Randy Bush wrote: >>> an intermediate AS, which does not validate but signs, could apply >> I=92d say that the intermediate AS who didn=92t verify the signatures = it >> received could be acting on bad info at any time, without any >> conspiring ASs around. The intermediate AS has no more assurance = than >> a non-bgpsec speaker that the route it receives is valid. >=20 > it is not worse than unsecured is a form of reasoning i do not buy. >=20 >=20 >> But the intermediate AS and any bgp4 (i.e. non-bgpsec speakers?) = peers >> have chosen to be insecure - I see no reason to be concerned. >=20 > same fallacious argument. we are supposed to be making things better, > not leaving them the same. Are you saying that any system that does NOT check the protections and = does not spot invalid signatures should still be protected? I think = that=92s a pretty tall order. My concern is with those who do check the signature but who, because = conspiring ASs =93violate the guarantee=94, do not get the bgpsec = protection in some way. David=92s suggestion that more of the data should be covered by the = signature still does not help the hapless intermediate AS who does not = check the signature, I would think. That AS could still fooled. So I = don=92t think that the new signature makes anything better for the = non-checkers. =97Sandy, speaking as a regular ol=92 member --Apple-Mail=_24BAB446-0D35-4EB7-8F04-8B07E074C64D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV5a4fAAoJEHplpQeet0IZhmQP/i30sYbTmxM0JK8cGApkFMiO wM6E4gISYd42WU174C/EgbzeaoVkZMLu/RlLMmqEAkOCv98yxNArsO7K3rU2N6Ic wk4yWSp3SDlLTrLun+3Xdzp3/LYkb9xzFHWHMXOKK9C40xV+Nw6VILph5Wik1dmm 9VxD8vvdNKl3Z4p2yUahV4BETBpTBT4+3IRJ/l0J6kot0AxJ8ruYvrsyMJQng6DY mkAsyS+vMwAiUsYDPBv4UON5Q0OM9idCHtbFmRhDZBUa/hXL+xQ3KEvDviNqm4kj 5ErPX7YZHAHTB5RCQHvZOs6/CG4Gygbraatyv/xF7JTdrlVZ/HPuqsMjr6INyRPl BDrN4GKyclHqXgYWI07zv+g6KsF5kV3XAD1IJfCRm5F4zXXHpOSn4lLpb+iQ8j4H VDZfr4xBI6Yn1t3emsbJzYlFTM/0c2zTcRVN9ht5OVHKpFYR+/ZhW2DR0hlGK/VW Tp9/Ttl0Kip329KxzTqf8fFEgrgDeTER7xHqQgo+ZRhNmoxEGDooM7rAZToOuwOs FIoPxvWXdOp77G3USjaFiZqeHBpU6U9esC2mL06Kfk4qterS9tkFbPTYhy4kXcRL PohOCtcqVwhYI3/0Y4eyUJJ5HD61bM9V7iWer1bSjoJJjS49om3AoDO1c65X+kn3 cGxYR8NbGOwCZriRza16 =vSyX -----END PGP SIGNATURE----- --Apple-Mail=_24BAB446-0D35-4EB7-8F04-8B07E074C64D-- From nobody Fri Sep 4 10:08:44 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21C51A8AA4 for ; Fri, 4 Sep 2015 10:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 afqu9YJh9L9t for ; Fri, 4 Sep 2015 10:08:41 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0119.outbound.protection.outlook.com [65.55.169.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC3A1A8A8C for ; Fri, 4 Sep 2015 10:08:37 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by BN1PR09MB012.namprd09.prod.outlook.com (10.255.201.148) with Microsoft SMTP Server (TLS) id 15.1.256.11; Fri, 4 Sep 2015 17:08:35 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0262.011; Fri, 4 Sep 2015 17:08:35 +0000 From: "Sriram, Kotikalapudi" To: "sidr wg list (sidr@ietf.org)" Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees Thread-Index: AQHQ5zRVYND+nmLqz0SZcM1xIM4p8g== Date: Fri, 4 Sep 2015 17:08:34 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.218.135] x-microsoft-exchange-diagnostics: 1; BN1PR09MB012; 5:X/HrB2Z/BiQHCdUw/gH4PWSVjTUvH/oyiICMMEKQCS3QyIc132tiujIqT4b1Nw3ckePPjjQHwvT1rlOZHjm0lLTo2YB11bQrn6elyKNWtzwTdqqT6kGtdKK9SR9Iyv2ILxqO8/phPZfHa4XSazcuxw==; 24:woMCLx3UfRpTcbtRLpaIQsv2zFMvYz0M06qWPPOtyC1YpdRpIM238cf5Q+z0yoVk0WuRTF740npoq2wcygD8dzGA4WXJn2EA5OPZIXeA7SY=; 20:KHQgmTNDp3az7q/VW3EjSkLJwSZVb9g42k+oTkLZbrC9Hfk1Muo+wqqwccdzyK7e0w06ODpKEyNNi4F3O8Z74Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB012; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(8121501046)(5005006)(3002001); SRVR:BN1PR09MB012; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB012; x-forefront-prvs: 06891E23FB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(5001860100001)(230783001)(105586002)(74316001)(66066001)(40100003)(2420400006)(68736005)(64706001)(81156007)(97736004)(450100001)(77156002)(106116001)(5002640100001)(19580395003)(102836002)(77096005)(106356001)(62966003)(46102003)(5003600100002)(122556002)(110136002)(50986999)(107886002)(87936001)(99286002)(5007970100001)(76176999)(5001830100001)(33656002)(5004730100002)(54356999)(15975445007)(92566002)(189998001)(10400500002)(86362001)(93886004)(5001960100002)(2900100001)(4001540100001)(2950100001)(101416001)(76576001)(7110500001)(10710500003)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB012; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Sep 2015 17:08:34.9952 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB012 Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2015 17:08:43 -0000 Doug and I have discussed the issues raised in this thread in some detail. We feel that the following considerations (with corresponding changes in th= e document)=20 would help resolve the issue(s) we are dealing with: 1. As mentioned already, signature should cover more data so that=20 the collusion vulnerability that David pointed out can be addressed. 2. It was a conscious design decision to not require (MUST) validation bef= ore path selection and signing in all cases. Lazy (or deferred) evaluation=20 (e.g., the ability to select and sign a path before validation) adds=20 performance / robustness options to implementations that address=20 real operational concerns (e.g., convergence time on table dumps, bootstrap= , etc.)=20 that were identified early in the BGPsec design process. 3. In consideration of the above (#2), the document should instead=20 strongly recommend that =93if an AS signs an update without verifying first= ,=20 it SHOULD return to the update at its earliest and verify, and forward=20 a new signed update, if necessary." Make this a strong BCP recommendation. 4. If this recommendation (#3) is followed, then other collusion/replay eff= ects=20 that have been identified on the list will be short lived=20 (e.g. Oliver=92s: http://www.ietf.org/mail-archive/web/sidr/current/msg072= 48.html ).=20 Adverse effects would be short lived, if the duration of deferment of=20 verification (if any) is short. Sriram From nobody Tue Sep 8 17:05:22 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA161B3823 for ; Tue, 8 Sep 2015 17:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 TDoWkzl5m1_v for ; Tue, 8 Sep 2015 17:05:19 -0700 (PDT) Received: from nm9-vm7.access.bullet.mail.gq1.yahoo.com (nm9-vm7.access.bullet.mail.gq1.yahoo.com [216.39.63.187]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928C51B3822 for ; Tue, 8 Sep 2015 17:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441757119; bh=K8f2LrT9Z9l+wnpln5lzbXSVMpS6yqldEBEqWvGvsVk=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=HW+t86K8zrV3Gt3obp6ffGE/Q61W2GXRzLgGOk3sanqIuaeTAVIJYaZJMXKnZwysw0r2Fwy17rz+1dK4qqfnrAAxc/zPtH+EjUrzbZK6GH5+W3lHfrbkyuHRpsfFYqq2KqVlqFe06v+peIqYCgxpGitr1AN1Ld58u6ea+3J5QI6Z8P6i4vXJfxpF1seFzquN+9K676RiLugKBXFJFclQbJ/pNg5C8aWJ+K5KepRrD9dYmfd0f0FS1aIZjtw3WuQJdI9jkHPa0ZglJUGJPlhyIBLc9DySNKrZVK4r1d7juoR3BMj0aiS0t+6WTmQ0y6yNiiTlrM9eDp6IxoCNsN8CqA== Received: from [216.39.60.169] by nm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 09 Sep 2015 00:05:19 -0000 Received: from [98.138.104.97] by tm5.access.bullet.mail.gq1.yahoo.com with NNFMP; 09 Sep 2015 00:05:18 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 09 Sep 2015 00:05:18 -0000 X-Yahoo-Newman-Id: 823992.55277.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: IV5DRywVM1lMbU8zSG8UFoXFIDChXjMEP.3gCqL9lDEMYRH qAo3ViZPnJxHTMx6xF2cVfUOUnVJobJK85H9vL.HCuRZ0Ud2PVb5sKqMsX99 jDjUipPxWQF6XfxcW0xpsQvlvrNflSX9BeEELT7P3cuY8PsoiD3CSPUiUP5f xvvx43MMl6TE9.bsMxF9I_q4qJdT7P8T.qc8ZUK5GYlzrlUy7.Au3c8emc5r GzvByccnVWnhGGav8yKQa4SdZ5vgzAi3.Pkm4tPhg66gHrO8G2WWMNVRsXU_ .j0_dtCHOXOUHzwUPHmhxkA88d5TmCKPygNWBtZXi8QF1IRKuLsr4sNceT2F pGcKYJUD4Brqdao1VYviY1M3XBUdWbswRPpzQX_VeijuRih8UGzWk4pJfAlQ NBCg5otTYiub55173OFvpZkCuOWx6_fRa6rEAkggQ_3NCkgAyWIpdPUtkgMN XcUTcurvygbDozvgB1Syq7YqieikgnmvHIx3y3QK.tjX2brtEsCz1p8orUMf 8YbewbJr0RKSPPUdCkaKKJVmRy8xOwzQ9zuTkmg-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id D52F61C6095 for ; Tue, 8 Sep 2015 20:05:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 08 Sep 2015 20:05:16 -0400 From: David Mandelberg To: In-Reply-To: <20150827024945.B46A51ABFFC4@minas-ithil.hactrn.net> References: <20150827024945.B46A51ABFFC4@minas-ithil.hactrn.net> Message-ID: X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 00:05:21 -0000 On 2015-08-26 22:49, Rob Austein wrote: > At Wed, 26 Aug 2015 17:26:24 -0400, David Mandelberg wrote: > ... >> I think this problem might be fixed if we modify the protocol to >> sign >> all of the preceding signed data (rather than just the immediate, >> previous signature). > > Agreed, assuming this means adding the (theoretically invariant) > fields from the data to be signed in section 4.1 to the data to be > signed in section 4.2. > > Taking "Origin AS Number" in section 4.1 as equivalent to "Signer's > AS > Number" in section 4.2, this leaves the algorithm suite identifier, > the AFI, the SAFI, and the NLRI to be added to the data to be signed > in section 4.2. I doubt that there's any practical attack based on > fiddling with the algorithm suite identifier (I'd expect any games > there to cause validation failure, end of story), but maybe somebody > has a more twisted imagination than mine, and, given that the > algorithm suite ID is one byte long, I don't think it's worth trying > to optimize that byte out of the section 4.2 signature. > > Presumably we want to keep the existing signature chaining, so I > wouldn't remove anything from the data to be signed in section 4.2, > just add the fields that are currently only present in section 4.1. > > David, if this is consistent with what you meant, cool, if not, say > on. It is not consistent with what I meant, so I'll be more explicit about what I meant. I meant to remove the signature chaining, and have each AS sign the data that is currently covered by signature chaining. I.e., each AS (origin or intermediary) would sign the same data structure (with different, but related, data in the structure): Target AS Number (4 octets) AS Count (4 octets) instances of: AS Number (4 octets) instances of: pCount (1 octet) Flags (1 octet) Algorithm Suite Id. (1 octet) AFI (2 octets) SAFI (1 octet) NLRI (variable) The sequence of AS Numbers is split from the sequence of (pCount, Flags) to preserve alignment, but the two sequences form a single logical sequence of (AS Number, pCount, Flags). (This could also be represented with 2 bytes of padding per AS, without 4-byte alignment, or with 3 parallel sequences; I don't really care which.) Regardless of the logical sequence's representation, the first (AS Number, pCount, Flags) entry corresponds to (Origin AS Number, pCount, Flags) from section 4.1. Subsequent entries correspond to (Signer's AS Number, pCount, Flags) from section 4.2, in order from the origin's next hop to the current signer. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Sep 8 17:52:08 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202971AC3C2 for ; Tue, 8 Sep 2015 17:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 0gmxOtI96ZPX for ; Tue, 8 Sep 2015 17:52:05 -0700 (PDT) Received: from nm2-vm9.access.bullet.mail.gq1.yahoo.com (nm2-vm9.access.bullet.mail.gq1.yahoo.com [216.39.63.240]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38B711A1B4A for ; Tue, 8 Sep 2015 17:52:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441759924; bh=EvjxwhCHWgw4jZ5ZP/e7NvXLdDG+eMHfNPmUg87+sis=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=d06eY035jyqQaCneY+zhlrGb2AkFwGBH3XLEwxvR9dui1eNCOArD+4w67lkaGa2Bpa1ort2r2fp1/zoJ7di5oZVOX7aaAH0azfIOdcuLU/SzHIWnI+WqLCJUv8BmjyipohLTDUr2n22tN7VGi9EjXqtn6uic+z3UCgnNmBjKFN5NG0qsD5ISw5Nw70El/2TBNNjFuDXmhCAjNakM7Y0rlPP8Aighl7TSRyyBrXjbkYPucCQ74gCENnRcqf78s0QD3e8mNlc1cgnTzjggH51ukJjRj6SP5hCRQoXu0nyieHb0OX9C7qG5v/A/QUkKGWKpFJlFbic4qvo8oCZkWnfZ3w== Received: from [216.39.60.176] by nm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 09 Sep 2015 00:52:04 -0000 Received: from [98.138.226.240] by tm12.access.bullet.mail.gq1.yahoo.com with NNFMP; 09 Sep 2015 00:52:04 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.ne1.yahoo.com with NNFMP; 09 Sep 2015 00:52:04 -0000 X-Yahoo-Newman-Id: 673662.76170.bm@smtp111.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5dOLrJoVM1lY2edIczf6e93XWDjMAaRjEenqGaQk2OxDi9r mR8MmKZbKxi0jIpGvjd6BdyKrpqcrFwav44rVbL78SbdewqOpWSp.W9vS6NC WJIrHdzB3slcs2wMPlds27ws4c3GjkLOcTIQl8Zk0MfvZ9e1f54oO03pmc1M llZbEBfWEG6F4U8mu0BmbmJcvINB2HUHxG53L4X7jCcNM_TUYgc1FzKDonPk DWShuznyZLWtW46dtBpDFLWr3ciyICZtWesDyFYowih_ZcmsJDOB0Z8Lskig SNcc9V.5KbBarCCtOpp_ESXSyESXr6Pft.8m4sfoiGwUopLzpvKu_XE.H73y 0XFmyjqvidrZdf3NJeiF352ZX0fOX2RF33kD9IGu8tHsOIhbuYU1h9a.xy8B 5arVI3VZg8KOn_prhZfja3U.4sC2ehGGLhvp5deqZwzB.7fsxuEJy3H6os87 dGfmAzPhw.G742dKrYOE05pNY0Aau3GWEH.0dBiB3pfD2pciCGKr2nAoAGu5 tch3dgyJWpVlnC780u2_OHg8iad6IBMYL46jEeg-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id B18461C6095 for ; Tue, 8 Sep 2015 20:52:03 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Tue, 08 Sep 2015 20:52:03 -0400 From: David Mandelberg To: In-Reply-To: References: , Message-ID: X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 00:52:07 -0000 On 2015-09-04 13:08, Sriram, Kotikalapudi wrote: > 3. In consideration of the above (#2), the document should instead > strongly recommend that =E2=80=9Cif an AS signs an update without verif= ying=20 > first, > it SHOULD return to the update at its earliest and verify, and=20 > forward > a new signed update, if necessary." Make this a strong BCP=20 > recommendation. Without replay protection, I don't see how this recommendation would=20 help. I.e., the old signed update would still be valid. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Sep 8 18:01:28 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3558A1A0007 for ; Tue, 8 Sep 2015 18:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 9uHbuuzIWKIm for ; Tue, 8 Sep 2015 18:01:25 -0700 (PDT) Received: from nm18-vm1.access.bullet.mail.gq1.yahoo.com (nm18-vm1.access.bullet.mail.gq1.yahoo.com [216.39.63.16]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1201B2D05 for ; Tue, 8 Sep 2015 18:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441760484; bh=uyKgZZ2W1R7p+9CfuwlbpjcNw/b6CRUJMkhFxDDGKvo=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=LD6g8/0OYCTpYoE+pmRA65dDCOhF7EjsUg1Zatd6oM56LbVp0uzX2tKQFJHYOToaPt1oGxxFKYq8MmaV8BMtp6gW5JROTzenKho1LhT6SxWxZ2d3gOGe2Tx4YWRiS3D0umq1Q0hfgGZAxF85/i8YRTRrjiG5R1HGXrv3uTyx240FlCBVa8BNpe3cHXh5Wk/zixGTYIWLllrEUg6Tvajz3kE4mFDbyCgNwBI5O4RvuiS7fu+KZznXPlr52b/xhdGDDdBJjRp1QdQKWZbF0o3SaAtcycX5mhlmprZMQxC943w1nqvr9gOxLPUIa/7TVRB407utHsqR2ErqLvKOYsxxZQ== Received: from [216.39.60.172] by nm18.access.bullet.mail.gq1.yahoo.com with NNFMP; 09 Sep 2015 01:01:24 -0000 Received: from [98.138.104.99] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 09 Sep 2015 01:01:24 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 09 Sep 2015 01:01:24 -0000 X-Yahoo-Newman-Id: 461376.38377.bm@smtp119.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: J0dzH2QVM1nU3v5.1KxSDVX2UIVZF5._.IBRcQVv_wP1DaT Vn.jJFS4DYYoSIDjgUOsxwx6EvEcWUwJwBZr8EC2rMTFtUboHV3Oz0x.xSGf LEwDwUzUl9wrEEKbCkvQMllAzAO2tGOw3ciF5vGcOapL4mM7I5Sf56Tnva.q FaY8Z1iO851QAM2jsuX_4xuXWd9KW.IPGzV_yaa4NXSuRj_mKyCc.c41FWN3 YPjdOcZ.o4nkJ14bLJg9X.dMxfwTTCDvzCWOy19W4ycP6EdSu8O1uO5waD6R og3s4c5P7tqP24SGOgHbO6pLIZooA1.UnIbWfXec_ZA_chVXCOPqbxFJo7Zs 1Wb574.dSH4cEJrxEKUJforyh5g62uAquFqxzmrcci2olL1Rdgu4mQBu9Tcr TFYldHdhL35daIS2FYhAtEB_Oa.s9Sq9.cYktZ7L0sF_oeSi1eiXlAZl57IM kmJ3NUJyYbMCqH5TofK4qxT4kmejxpuK.OPbnYK7Ao8CSlfw3UWd_SRohf_i vDaZT027jktAXO4iswcez6xvqdenzcvoS9o7_mQ-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id CDA631C6095 for ; Tue, 8 Sep 2015 21:01:22 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 08 Sep 2015 21:01:22 -0400 From: David Mandelberg To: In-Reply-To: References: <20150827175826.A35401AC51E2@minas-ithil.hactrn.net> Message-ID: X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 01:01:27 -0000 On 2015-08-27 15:23, Borchert, Oliver wrote: > If I understand Davids attack vector correct than the attack would > look > as follows: > > For the path -> A -> B -> C -> D -> E with A and D conspiring and B > and C > only signing but not validating: > > A signs the path to D and not to B but sends it to B. Because B and C > do not validate, just sign they forward the path to D. > D removed B and C from the path and forwards the path as -> A -> D > to E. > Now E verifies the path as valid and moves on. > > If this is what David had in mind then I agree that the security > guarantee > in 7.1 does not hold up. This is one type of attack that uses the issue I raised, but this specific attack doesn't seem problematic to me. A and D can always set up a BGPsec tunnel to accomplish the same result of removing B and C from the path, and there's not much we can do to stop that. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Sep 8 18:07:19 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96CB1A00E3 for ; Tue, 8 Sep 2015 18:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 vNb6if8OSwb5 for ; Tue, 8 Sep 2015 18:07:17 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891251B2A4B for ; Tue, 8 Sep 2015 18:07:11 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 1591B3980B for ; Wed, 9 Sep 2015 01:07:11 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 1682A1B25E5C for ; Tue, 8 Sep 2015 21:07:09 -0400 (EDT) Date: Tue, 08 Sep 2015 21:07:09 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20150827024945.B46A51ABFFC4@minas-ithil.hactrn.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20150909010709.1682A1B25E5C@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 01:07:19 -0000 Hmm, I would have thought we'd want to keep the chaining, in the sense that non-originating would sign the previous signature. I've no real objection to signing everything else again, it's just removal of the previous signature that I find odd here. The benefit I see to keeping the signature chaining is that it adds an ordering constraint to the signatures (signature A must have been created after signature B), corresponding to the order in which we expect the update to travel between signers. This seems like a good thing, and I don't see why we'd want to remove it. As you've demonstrated, it doesn't remove all possible forms of mischief, but it raises the bar a bit, and it's cheap, so why not? Am I missing something? Where's the benefit in removing the chaining? From nobody Tue Sep 8 18:21:58 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E3D1B31B8 for ; Tue, 8 Sep 2015 18:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 EMsLWETNjEJI for ; Tue, 8 Sep 2015 18:21:55 -0700 (PDT) Received: from nm9-vm2.access.bullet.mail.gq1.yahoo.com (nm9-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.37]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3604B1B31B4 for ; Tue, 8 Sep 2015 18:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441761714; bh=SLxY3n+GXV+nY1QYlAh2Wg+67xWwOsxVywK7BuRLcgM=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=Mwt7o8DKH2gpwb2IRiARD5U8AbEKC6ebj7eIXOP0UlDKo3KjRGTORVk8hTS7qz1OAulrNdf6kZMxHzcag9rJeGzFISulX3ZPCbXavA07RXGmftjxqgza1wmwX+DKIG9hvnSoK+URaI9zPtTK0YfKvaEhbUTFji4YRyN0qHZO6ywQ0LGBtR2dcMLUqKkenKIPwYp+pparQtMFom4oq0YBgANiXMWLGo+rtQCwQHZ6oR7GPbAfl+AT+mRgGPzafWekJflsRJjCUApVPIrYjJK+fqTNsdpzoZ9xIApJGaNKm0Ta6x3LFdU5IWhHorkC49V/5zpP16Lb4FuueiN/o9jaig== Received: from [216.39.60.166] by nm9.access.bullet.mail.gq1.yahoo.com with NNFMP; 09 Sep 2015 01:21:54 -0000 Received: from [98.138.226.240] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 09 Sep 2015 01:21:54 -0000 Received: from [127.0.0.1] by smtp111.sbc.mail.ne1.yahoo.com with NNFMP; 09 Sep 2015 01:21:54 -0000 X-Yahoo-Newman-Id: 697821.63906.bm@smtp111.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1LxQ7HgVM1lCBTK8CdJBXBtl6yPDp._.IIU6vVUZmeHGZCl xDVnH2nNP2mwlxsKDw0V5QsJbwNsyHngwbJM.m8peqFp1cTySAvCgxGFjk5u YcH0PL1BF3.rBC6ERYI0W8dskZiJZotZk.Nz2ZVDSNifZCPg5BSDXUfkQQAm A2b37I3dPuYhQj0W9LeTQ_Zgi4NzDSAMsm8aVii0UoZdQtRxqeowh2XOCeIx qxbYhiu92SvKTL7Dy9Z_wYRk0swcekPatqF2p1Y7Db8ZoCdTnycEDZwOXX0e JJCbBln_QyGhNhenp4oN_glOjWh3no6EewBEgvwKfqbRpTkAxUEhuQDCKHMl dx_6gwz8r7oCHZwSdfhZV1B48Bm4296bIdxOO5vkDBjVFQTtvNJaTWMQuWiN gdXM7E14T0PZEwxsuKtLjBTJGFYEDcvclfUs2KMssWAtaaoDqvAJu0k3LewZ sjzJKvuOBuf7U4F8B.5b_KfJmHWhro3YuYxvM0m9rZpQ.5PqjtwKv2u9qbeF rE6PC9ACnVrkLS.YQKb0ai2ht8bf7I6ukKSdtWg-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 6CB721C6095 for ; Tue, 8 Sep 2015 21:21:52 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 08 Sep 2015 21:21:52 -0400 From: David Mandelberg To: In-Reply-To: <20150909010709.1682A1B25E5C@minas-ithil.hactrn.net> References: <20150827024945.B46A51ABFFC4@minas-ithil.hactrn.net> <20150909010709.1682A1B25E5C@minas-ithil.hactrn.net> Message-ID: <4a6b03813484d7cd53bca4a9a8d86b83@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 01:21:57 -0000 On 2015-09-08 21:07, Rob Austein wrote: > Hmm, I would have thought we'd want to keep the chaining, in the > sense > that non-originating would sign the previous signature. I've no real > objection to signing everything else again, it's just removal of the > previous signature that I find odd here. > > The benefit I see to keeping the signature chaining is that it adds > an > ordering constraint to the signatures (signature A must have been > created after signature B), corresponding to the order in which we > expect the update to travel between signers. This seems like a good > thing, and I don't see why we'd want to remove it. As you've > demonstrated, it doesn't remove all possible forms of mischief, but > it > raises the bar a bit, and it's cheap, so why not? I agree that signature chaining provides the guarantee you stated, that signatures were generated in order. But in the presence of non-validating signers, I don't think it provides any other guarantee. What does the guarantee about signature order provide? I don't see how it's useful, but I could be missing something. > Am I missing something? Where's the benefit in removing the > chaining? There's no benefit to removing it, except that I don't see any benefit to keeping it (if we sign the full data, as I described). -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Sep 8 19:03:46 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145611A6FC4 for ; Tue, 8 Sep 2015 19:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dzq2ibLtga6S for ; Tue, 8 Sep 2015 19:03:43 -0700 (PDT) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCD91A9096 for ; Tue, 8 Sep 2015 19:03:42 -0700 (PDT) Received: from LIUXD (unknown [218.241.103.6]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BZYIR4k+9VV1LCBw--.601S3; Wed, 09 Sep 2015 10:03:36 +0800 (CST) From: "Yu Fu" To: Date: Wed, 9 Sep 2015 10:03:45 +0800 Message-ID: <000c01d0eaa3$c2bd0240$483706c0$@cn> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdDqFjYBd600LbRLSgiB2hJj5gN/FAAhaoUA Content-Language: zh-cn X-CM-TRANSID: AQAAf0BZYIR4k+9VV1LCBw--.601S3 X-Coremail-Antispam: 1UD129KBjvJXoW7ZF1DZrWUXw4UtFyDur1ftFb_yoW8Gr4Upa 93ua13tF18JFn3tay7Jw4qvw4Iva9xCaykXryaqw15Zan8Gryaqrn3KFW5Xr98Crn0kFZ0 qF12v3WUtry8ZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUkab7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAC Y4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJV W8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lc2xSY4AK67AK6r4UMxAI w28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr 4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwIxG rwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8Jw CI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY 6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07jYNtxUUUUU= X-CM-SenderInfo: pix13q5fqqxugofq/ Archived-At: Subject: [sidr] FW: New Version Notification for draft-fu-sidr-unexpected-scenarios-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 02:03:45 -0000 Hi all, We have submitted a new draft to describe some unexpected scenarios = where a CA allocates resources to the sub-node caused by misoperation or malicious operation in RPKI. Some = experimental results are also presented to simulate these scenarios. In order to avoid the issues or reduce the = related side- effects described in the draft,=20 some solutions may be needed. Your comments are appreciated. BR Yu A new version of I-D, draft-fu-sidr-unexpected-scenarios-00.txt has been successfully submitted by Yu Fu and posted to the IETF = repository. Name: draft-fu-sidr-unexpected-scenarios Revision: 00 Title: Scenarios of unexpected resource assignment in RPKI Document date: 2015-09-08 Group: Individual Submission Pages: 17 URL: = https://www.ietf.org/internet-drafts/draft-fu-sidr-unexpected-scenarios-0= 0.txt Status: = https://datatracker.ietf.org/doc/draft-fu-sidr-unexpected-scenarios/ Htmlized: = https://tools.ietf.org/html/draft-fu-sidr-unexpected-scenarios-00 Abstract: There are some unexpected scenarios where a CA allocates resources to the sub-node caused by misoperation or malicious operation of CA in RPKI. Then some mechanisms may be needed to avoid these scenarios to happen. This document describes these scenarios and related experiments are presented. = =20 From nobody Tue Sep 8 20:15:22 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B701B39F3 for ; Tue, 8 Sep 2015 20:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 GvTQwGFk_IGm for ; Tue, 8 Sep 2015 20:15:20 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78F621B39EB for ; Tue, 8 Sep 2015 20:15:20 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id D59C739811 for ; Wed, 9 Sep 2015 03:15:19 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 7CDD31B27492 for ; Tue, 8 Sep 2015 23:15:17 -0400 (EDT) Date: Tue, 08 Sep 2015 23:15:17 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <4a6b03813484d7cd53bca4a9a8d86b83@mail.mandelberg.org> References: <20150827024945.B46A51ABFFC4@minas-ithil.hactrn.net> <20150909010709.1682A1B25E5C@minas-ithil.hactrn.net> <4a6b03813484d7cd53bca4a9a8d86b83@mail.mandelberg.org> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20150909031517.7CDD31B27492@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 03:15:22 -0000 At Tue, 08 Sep 2015 21:21:52 -0400, David Mandelberg wrote: > > What does the guarantee about signature order provide? I don't see how > it's useful, but I could be missing something. I can't point to any concrete threat. Just a suspicion that we should grab a cheap opportunity to reduce the number of potential violations of the Principal of Least Astonishment. From nobody Wed Sep 9 07:18:56 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECAF1AC39D for ; Wed, 9 Sep 2015 07:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cHliw_70_Vsf for ; Wed, 9 Sep 2015 07:18:52 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D2D1A88AC for ; Wed, 9 Sep 2015 07:18:52 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 29B0D28B003D; Wed, 9 Sep 2015 10:18:52 -0400 (EDT) Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 0B5901F8035; Wed, 9 Sep 2015 10:18:52 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) Content-Type: multipart/signed; boundary="Apple-Mail=_26E19790-2A63-4C41-9CBD-32906837EAA8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.1 From: Sandra Murphy In-Reply-To: <9FCE9E00-B8BE-48CA-8B75-B2D31957BCA1@tislabs.com> Date: Wed, 9 Sep 2015 10:18:40 -0400 Message-Id: References: <51693906dadd4c8eb52dfea1c7e16feb@mail.mandelberg.org> <9FCE9E00-B8BE-48CA-8B75-B2D31957BCA1@tislabs.com> To: David Mandelberg X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: sidr@ietf.org, Sandra Murphy Subject: Re: [sidr] WG adoption call for draft-dseomn-sidr-slurm X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 14:18:55 -0000 --Apple-Mail=_26E19790-2A63-4C41-9CBD-32906837EAA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This working group adoption call is supposed to end tomorrow. So far, = there has been weak support for adoption. If you are interested in this = work, speak up. =97Sandy, speaking as one of the wg co-chairs On Aug 27, 2015, at 7:33 PM, Sandra Murphy wrote: > The authors of draft-dseomn-sidr-slurm adoption have requested working = group adoption. >=20 > A working group adoption call starts now and will end 14 days from now = on 10 September. >=20 > Please respond on the list to say whether you support adoption of this = work as a working group work item AND whether you will participate in = the discussion. >=20 > Remember that working group consensus to adopt the work needs = responses, not just absence of objection, so speak up. >=20 > --Sandy, speaking as one of the wg co-chairs >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_26E19790-2A63-4C41-9CBD-32906837EAA8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV8D/MAAoJEHplpQeet0IZjugQAKBfc7s8QdlJILuNJd6//WD+ 9koSVZ0NM0HlIDq96J10f4k9zuT3EU/vyK6O/IL1ktbg3970SZVACVbpdWwD5ICL K+K0QF9T3MBM9S+M73EEMgMph+ydcZYqPuiTembIFL20hUqJpLQO6qHPNH0IsuJ2 nRcrEQQTjEA8On5ARI2StfCL2zY2YHmITIdQHQX0QSdp4jCniHWCnXLQ6HkQHVCh 2T3WgUnCi9AyjX8e57+lyIIN/robVYmO7Pstzs4EYWNwDK3vhdOPNhJtnxjk48xP mL2DADdLdzS60wLbzAa29eyLEkoPs84qw7+n+0Fe/6pVmnprXGSXm5VtCpkAcJ3J aRawNurj7tqCb4rAEaDA3HEweyZ80pcWj8doe/ZVxwgTpEIBhh6dXZCy+V6XpgAL YipRYyQDlaJn16v6HghxyPecyJaMghXxVRcihTR4RXmQHgfA9oSx3WcrnT1CzA7m eLanBTkXl3PfQKrj84ADyO9GRWEZ7Hd2C2PhcoXoQtpFq8MfJyWbe6F9jDvVCq12 O8GSp9L6hbHLuTNFezIExu4QvKWkIFBXQm8I/IriDJ9MMCeNGMhaFQjDOcTWQ7Iy xbUju46g2I5rlTIAJemxO5vjF4+rrFF5ttLQw4sXA/56FcUEE3W1CdTPMVa5ZNrF kTxDhVWu9hPna2vJYlk4 =uBr/ -----END PGP SIGNATURE----- --Apple-Mail=_26E19790-2A63-4C41-9CBD-32906837EAA8-- From nobody Wed Sep 9 09:16:20 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1FC1B3D87 for ; Wed, 9 Sep 2015 09:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dpV6N0PSHVq8 for ; Wed, 9 Sep 2015 09:16:17 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [147.28.0.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A001B3CDC for ; Wed, 9 Sep 2015 09:16:17 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 0CED539818 for ; Wed, 9 Sep 2015 16:16:17 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 4806C1B2EDA3 for ; Wed, 9 Sep 2015 12:16:15 -0400 (EDT) Date: Wed, 09 Sep 2015 12:16:15 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <51693906dadd4c8eb52dfea1c7e16feb@mail.mandelberg.org> <9FCE9E00-B8BE-48CA-8B75-B2D31957BCA1@tislabs.com> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20150909161615.4806C1B2EDA3@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] WG adoption call for draft-dseomn-sidr-slurm X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 16:16:18 -0000 As mentioned in Praha, I'm not entirely convinced that we need a standard for this. Not opposed either, more reserving judgement. With that caveat, I support adoption (as something the WG should at least be thinking about, whether we decide we need a standard or not) and am willing to read and discuss. From nobody Thu Sep 10 08:19:28 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887951B5FE2 for ; Thu, 10 Sep 2015 08:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 fxBim7AUGtQj for ; Thu, 10 Sep 2015 08:19:26 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (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 17A131B4294 for ; Thu, 10 Sep 2015 08:19:26 -0700 (PDT) Received: by ykdg206 with SMTP id g206so60727715ykd.1 for ; Thu, 10 Sep 2015 08:19:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Gl5t8THwqZMyGGK34eWegwse2y6yfHusvxgwVvUn5y0=; b=Aj8sIwgBoVy+cnHjYvyW6l2Tu9dxmFsjWuXfe22bRaxV9DGqCfipw1q5QPpI4btrNS GWW4LmGFlY6E1QPNQDEL2z9yu6lLTeAh5QoEz1aqPIbrF8Qc640lLkvQNF+WFrApesW+ C3IoJhh2y/ZBR44RL718ClztaAxHcjf46RBeUPP7zjeFIdDPdkUZKbWdAABFdpKAGm/F ogK+a4ph8YJgJbVzVG50Ke/BU4ISPxNxvbYG7VMifm3CZk/jjFn86r66MpVOfutGPfFr aaUNw+AXyQLQvv880w+BWdTHEL7wcffrjccQTH1Of3w3kPiz2t5ZkAdhSCZBShLcw17d NeFA== MIME-Version: 1.0 X-Received: by 10.129.102.198 with SMTP id a189mr46272949ywc.19.1441898365406; Thu, 10 Sep 2015 08:19:25 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.237.135 with HTTP; Thu, 10 Sep 2015 08:19:25 -0700 (PDT) In-Reply-To: <5592F128.7030908@bbn.com> References: <55828BEC.9010605@ops-netman.net> <5592F128.7030908@bbn.com> Date: Thu, 10 Sep 2015 11:19:25 -0400 X-Google-Sender-Auth: pn-kKF9Z7-pC3NoadS_AopbSNEQ Message-ID: From: Christopher Morrow To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-rpsl-sig - End Jul 02 2015 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 15:19:27 -0000 Howdy! there was a flurry of activity, some comments that seemed useful.... I didn't see an update to the doc though yet? It's cool if that's waiting in the wings behind other work, just checking on status though. On Tue, Jun 30, 2015 at 3:42 PM, Stephen Kent wrote: > I made a few edits to correct spelling errors. I also have some questions > about > ambiguities in the text and some suggestions for adding text to warn relying > parties > about the danger of assuming that all signed attributes in an RPSL object > are > trustworthy/valid. > > I have attached a PDF of the MS Word reviewed text. > > Steve > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From nobody Thu Sep 10 10:15:07 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFF71B3A17 for ; Thu, 10 Sep 2015 10:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 srCPdU7LYbSW for ; Thu, 10 Sep 2015 10:15:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBD51B377E for ; Thu, 10 Sep 2015 10:15:04 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:59366 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Za5R9-00027f-0Q; Thu, 10 Sep 2015 13:15:03 -0400 To: Christopher Morrow References: <55828BEC.9010605@ops-netman.net> <5592F128.7030908@bbn.com> From: Stephen Kent Message-ID: <55F1BA96.8070502@bbn.com> Date: Thu, 10 Sep 2015 13:15:02 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-rpsl-sig - End Jul 02 2015 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 17:15:06 -0000 Chris, Since I was just a person offering suggested edits, I presume this message is really directed to the doc authors, right? Steve > Howdy! > there was a flurry of activity, some comments that seemed useful.... I > didn't see an update to the doc though yet? > > It's cool if that's waiting in the wings behind other work, just > checking on status though. > > On Tue, Jun 30, 2015 at 3:42 PM, Stephen Kent wrote: >> I made a few edits to correct spelling errors. I also have some questions >> about >> ambiguities in the text and some suggestions for adding text to warn relying >> parties >> about the danger of assuming that all signed attributes in an RPSL object >> are >> trustworthy/valid. >> >> I have attached a PDF of the MS Word reviewed text. >> >> Steve >> >> >> >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> From nobody Thu Sep 10 10:44:13 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7431B3217 for ; Thu, 10 Sep 2015 10:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ivXfY53szYZ8 for ; Thu, 10 Sep 2015 10:44:09 -0700 (PDT) Received: from mail-yk0-x233.google.com (mail-yk0-x233.google.com [IPv6:2607:f8b0:4002:c07::233]) (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 4BC2B1A8BB1 for ; Thu, 10 Sep 2015 10:44:09 -0700 (PDT) Received: by ykdg206 with SMTP id g206so65429869ykd.1 for ; Thu, 10 Sep 2015 10:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=KKfVjOZTiFyDPCUqui0lt0aQT+U4qGawAnOrLYmrwuE=; b=ONFwZ/rv15eTpCB5rOUXlOCqfTjh1/aXliB4RsEyVoEF37zPFpgu5q1DDCbqsmIYT7 EjTK1ndl+mPmPvEbK4lEGYul2UXqFpyQX0zg4PCR78G5ll3u/08H6D20s79GVXHxVEYj e6AUnANCaHuU54Kv22WIp4/8QYJg5JNmCTh8j//mxr4bptBpO/op21Sfr5nGCPDca8V0 LrkWvg70rK05qLiFmajLSM648Nj5iqu6r8+OQLYpBuD9v2naUiAmklVy9sHpcxLgYOsI Hg3/Bs4Jw0cp8WGA7G2A9IkpKtLyUtN3Z9sfwUFzHdJ/R4BX33H4bV+pzpY83ZdyHe/R limg== MIME-Version: 1.0 X-Received: by 10.129.102.198 with SMTP id a189mr47233176ywc.19.1441907048604; Thu, 10 Sep 2015 10:44:08 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.13.237.135 with HTTP; Thu, 10 Sep 2015 10:44:08 -0700 (PDT) In-Reply-To: <55F1BA96.8070502@bbn.com> References: <55828BEC.9010605@ops-netman.net> <5592F128.7030908@bbn.com> <55F1BA96.8070502@bbn.com> Date: Thu, 10 Sep 2015 13:44:08 -0400 X-Google-Sender-Auth: Y4kHc9tZTAbfA39lB7g8q-QDBR8 Message-ID: From: Christopher Morrow To: Stephen Kent Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-rpsl-sig - End Jul 02 2015 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 17:44:10 -0000 On Thu, Sep 10, 2015 at 1:15 PM, Stephen Kent wrote: > Chris, > > Since I was just a person offering suggested edits, I presume this message > is really directed to the doc authors, right? > yes indeed... to the authors and other folk who offered suggested edits (if they did hear back that'd be good to know) -chris > Steve > > > >> Howdy! >> there was a flurry of activity, some comments that seemed useful.... I >> didn't see an update to the doc though yet? >> >> It's cool if that's waiting in the wings behind other work, just >> checking on status though. >> >> On Tue, Jun 30, 2015 at 3:42 PM, Stephen Kent wrote: >>> >>> I made a few edits to correct spelling errors. I also have some questions >>> about >>> ambiguities in the text and some suggestions for adding text to warn >>> relying >>> parties >>> about the danger of assuming that all signed attributes in an RPSL object >>> are >>> trustworthy/valid. >>> >>> I have attached a PDF of the MS Word reviewed text. >>> >>> Steve >>> >>> >>> >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>> > From nobody Thu Sep 10 12:09:25 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18C541B3ED4 for ; Thu, 10 Sep 2015 12:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 SXqYgmSK0IeK for ; Thu, 10 Sep 2015 12:09:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1C11B3ED5 for ; Thu, 10 Sep 2015 12:09:21 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:51322 helo=COMSEC.fios-router.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Za7Dk-0002uy-Oo for sidr@ietf.org; Thu, 10 Sep 2015 15:09:20 -0400 To: sidr@ietf.org References: <20150827024945.B46A51ABFFC4@minas-ithil.hactrn.net> <20150909010709.1682A1B25E5C@minas-ithil.hactrn.net> <4a6b03813484d7cd53bca4a9a8d86b83@mail.mandelberg.org> From: Stephen Kent Message-ID: <55F1D560.9070608@bbn.com> Date: Thu, 10 Sep 2015 15:09:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <4a6b03813484d7cd53bca4a9a8d86b83@mail.mandelberg.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 19:09:24 -0000 David, > > ... > > What does the guarantee about signature order provide? I don't see how > it's useful, but I could be missing something. At least initially, sig order was required to match the AS transit order, to ensure that the AS transit order is accurately represented. Is that no longer true? Steve From nobody Thu Sep 10 17:28:13 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 758A71B3D62 for ; Thu, 10 Sep 2015 17:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 hS3QPeuuehzW for ; Thu, 10 Sep 2015 17:28:10 -0700 (PDT) Received: from nm10-vm2.access.bullet.mail.bf1.yahoo.com (nm10-vm2.access.bullet.mail.bf1.yahoo.com [216.109.114.209]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3FF11B46B7 for ; Thu, 10 Sep 2015 17:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1441931289; bh=nrZ99CWQ2/FTqq05TkfPAzC/pJsPzAC0k5V+upDNEZc=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=bGmZ/A7KCOhAINdmp/Ucgt7xxjs4IM1aKZsAWU88Wa8P6JRCzJFHkCcf5wvoa+Y3lw2xo9FEkKYqzNmlO2c1A/C8xv3ZgFmbLwoSdviu5s+G6wczzfeTxa5qXwHv21n9j2ZAxaWoKqOZ3mE33xS/Cls0XvlRQlME3w0H5p9AWLIWvDX1vOEKzrrxWHT2nxZ1IgXDNEYxg4BQJJftBNh/x1pxRoKQ0tWQ+DqAPHEC1foxDDNyOc05mMtnZ9vSbYEvBg1p1JUMDkH2MzQd4xVRnp4H6uT1wS/3Ja8cd8gSr/44k0/bb4Qi0NwGwxcXUFhuR54afMwEtFjdY3m2JV8vAA== Received: from [66.196.81.156] by nm10.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Sep 2015 00:28:09 -0000 Received: from [98.138.226.242] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 11 Sep 2015 00:28:09 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.ne1.yahoo.com with NNFMP; 11 Sep 2015 00:28:08 -0000 X-Yahoo-Newman-Id: 898999.59398.bm@smtp113.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LhTDSkgVM1mgai2JUgr7ebDemlI9ppdvD.jjpmS2RWQt7Iw mseqUBbIPew27jxW12vRKhIbEEm6r2XQ7siBAidHdRXlRX.NgZ8buZZKXKvC EdpUgEWcZM.V9RN5MMZz4dpAj85ucal14Zy2AmpwekkdVUfdf0rVwms0zMie .fMOqX2m6qWXp1CI3z8ASoY0FxYVzAFf0jX06qfWzMOZ24pE_M1WFyMKv77i lcnZAZmro8LT1ulAZmtBx1JeuQH22lS02kBwpUvEoBGnq_hZwU4E3XmmswZK U.qWa2nnk_ACpnIj0FS.htqYwQ_v8Lf2dKlSiEeFcyyppWqS52kgQDhcIDDQ UOuMBBVdnOH5OvFxnwNnzWCt2Utz9kmZ.00VpV1jR.i5kKzfHafNiHhJzmHn FYfc5JQB37luOAeZu3Ehe9WkmeIWdhDuE78LIh.6c7fsOfbldDsSkuCqLQIl L5XbJ0eWm7sgZ5AVB2VM90sYNGuMRLWIVfsZYbDEjKQ57GLJy2NPYxbbKW56 dzrrsDoX9grDTxkNjcArm.Xc_Boii0UKe2je36g-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id EE7DB1C6095 for ; Thu, 10 Sep 2015 20:28:06 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 10 Sep 2015 20:28:06 -0400 From: David Mandelberg To: In-Reply-To: <55F1D560.9070608@bbn.com> References: <20150827024945.B46A51ABFFC4@minas-ithil.hactrn.net> <20150909010709.1682A1B25E5C@minas-ithil.hactrn.net> <4a6b03813484d7cd53bca4a9a8d86b83@mail.mandelberg.org> <55F1D560.9070608@bbn.com> Message-ID: X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 00:28:11 -0000 On 2015-09-10 15:09, Stephen Kent wrote: > At least initially, sig order was required to match the AS transit > order, to ensure that the > AS transit order is accurately represented. Is that no longer true? Are you talking about (1) the order of the signatures on the wire, (2) the order of which AS path is covered by which signature, or (3) the chronological order in which the signatures are generated? I think Rob and I were talking about (3), but Rob should tell me if I misunderstood him. For (1), the order needs to specified such that each signature can be correctly verified. Having the order of the signatures match the AS transit order seems like the most sensible way to do this. For (2), I think it's critical that each signature covers that correct AS path, in the correct order. For (3), the signatures will typically be generated in order, but I don't see the value of enforcing that. I.e., while I don't see the point of pre-computing signatures before including them in a BGPsec UPDATE, I also don't see any harm in it. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Mon Sep 14 03:04:06 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA561B35B6 for ; Mon, 14 Sep 2015 03:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 PRVgnMYZWDAr for ; Mon, 14 Sep 2015 03:04:04 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 E9AB91A90AC for ; Mon, 14 Sep 2015 03:04:03 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by molamola.ripe.net with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1ZbQc9-0005pt-5H; Mon, 14 Sep 2015 12:03:59 +0200 Received: from sslvpn.ripe.net ([193.0.20.230] helo=vpn-27.ripe.net) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1ZbQc8-0004FO-Vh; Mon, 14 Sep 2015 12:03:57 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 $2102$) From: Tim Bruijnzeels In-Reply-To: <9FCE9E00-B8BE-48CA-8B75-B2D31957BCA1@tislabs.com> Date: Mon, 14 Sep 2015 12:03:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6D972F9E-453A-4178-8EE3-5BF212965CEA@ripe.net> References: <51693906dadd4c8eb52dfea1c7e16feb@mail.mandelberg.org> <9FCE9E00-B8BE-48CA-8B75-B2D31957BCA1@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.2102) X-ACL-Warn: Delaying message 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: 784d7acfe6559f2a0b602ec6519a07191ed6b2587c339f675cf4d0895763158d Archived-At: Cc: sidr@ietf.org, David Mandelberg Subject: Re: [sidr] WG adoption call for draft-dseomn-sidr-slurm X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2015 10:04:05 -0000 Hi, I understand it's past the end of call date, but I was fortunate enough = to have a three week holiday that unfortunately covered these two weeks. In any case I too support adoption. As I said at the mic in Prague, we = are already doing some of this in the RIPE NCC RPKI Validator and having = a standard for this would be useful. Tim > On 28 Aug 2015, at 01:33, Sandra Murphy wrote: >=20 > The authors of draft-dseomn-sidr-slurm adoption have requested working = group adoption. >=20 > A working group adoption call starts now and will end 14 days from now = on 10 September. >=20 > Please respond on the list to say whether you support adoption of this = work as a working group work item AND whether you will participate in = the discussion. >=20 > Remember that working group consensus to adopt the work needs = responses, not just absence of objection, so speak up. >=20 > --Sandy, speaking as one of the wg co-chairs >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Sep 14 17:54:48 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B171B3B8E for ; Mon, 14 Sep 2015 17:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ObQE1xsX5wdi for ; Mon, 14 Sep 2015 17:54:43 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCC31B3B6E for ; Mon, 14 Sep 2015 17:54:42 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (10.163.43.143) by CY1PR09MB0796.namprd09.prod.outlook.com (10.163.43.146) with Microsoft SMTP Server (TLS) id 15.1.268.17; Tue, 15 Sep 2015 00:54:39 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([10.163.43.143]) with mapi id 15.01.0268.017; Tue, 15 Sep 2015 00:54:39 +0000 From: "Sriram, Kotikalapudi" To: David Mandelberg , "sidr@ietf.org" Thread-Topic: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees Thread-Index: AQHQ5zRVYND+nmLqz0SZcM1xIM4p8p4zZROAgAlrFm4= Date: Tue, 15 Sep 2015 00:54:39 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.218.111] x-microsoft-exchange-diagnostics: 1; CY1PR09MB0796; 5:PVaX2w6ApFTVQpjxiuZvdlJQXtcdS9Yay3F1lw47wFsm9yI4MH4xP8ewE/kw3O/oL4UI8idGNxzL2k+3iiNtNmXustDDflx2yo0PEBV+hrAXMPR9DcoFoX3xX1qY3pO9OwCUuwOPFI56Ijo+hMDKZA==; 24:8H8dAbZ8X2llMokcn4yJRvUz9YwH6ETSEulY2e0+ahB7Zz1Uj/Ah8xlrevVRX31X4WMeI71w7cor1blVBsHv4gjzTCSawe7IDySTMbhY81E=; 20:8dt7FtnT5QCPucH4iOG1mOqiru5C854V4X4S1rKnIvifhB+pekpIowqlSryQ7ZOb4Oqytzdri44pvmk8QZg28Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0796; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(520075)(8121501046)(520078)(3002001); SRVR:CY1PR09MB0796; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0796; x-forefront-prvs: 070092A9D3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(77156002)(66066001)(81156007)(4001540100001)(64706001)(76576001)(2900100001)(5001830100001)(2501003)(10400500002)(40100003)(11100500001)(5004730100002)(5007970100001)(122556002)(74316001)(92566002)(2950100001)(68736005)(86362001)(189998001)(77096005)(46102003)(102836002)(5002640100001)(5001860100001)(230783001)(97736004)(5001960100002)(106116001)(50986999)(107886002)(54356999)(33656002)(5001770100001)(101416001)(76176999)(93886004)(105586002)(106356001)(62966003)(99286002)(87936001)(5003600100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0796; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2015 00:54:39.1725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0796 Archived-At: Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 00:54:46 -0000 >> 3. In consideration of the above (#2), the document should instead >> strongly recommend that =93if an AS signs an update without verifying >> first, >> it SHOULD return to the update at its earliest and verify, and >> forward >> a new signed update, if necessary." Make this a strong BCP >> recommendation. > >Without replay protection, I don't see how this recommendation would >help. I.e., the old signed update would still be valid. > In the example with -- > A --> B --> C --> D -->, if B and C=20 (the ones that were signing but not verifying) return to the update to veri= fy,=20 then they will realize that the update they last signed (for the prefix) wa= s invalid, and will propagate an alternate valid signed announcement or=20 send a withdrawal message to D. At this point, B and C have taken their corrective action. Their well-behaving neighbors (others besides D) will act on=20 the new valid announcement or the withdrawal. But if D is still malicious and suppresses the new valid announcement or the withdraw, then that would be=20 a classic withdraw suppression / replay attack. (B and C are not contributing to collusion anymore at this point.) And the solution at that point is whatever remedy=20 draft-ietf-sidr-bgpsec-rollover-04 offers.=20 Sriram From nobody Mon Sep 14 18:12:29 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0ACF1A885F for ; Mon, 14 Sep 2015 18:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 dyR-Cv3a6YfE for ; Mon, 14 Sep 2015 18:12:26 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3643F1B36B2 for ; Mon, 14 Sep 2015 18:12:23 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1ZbenD-0006Uw-SB; Tue, 15 Sep 2015 01:12:20 +0000 Date: Tue, 15 Sep 2015 07:12:16 +0600 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "sidr@ietf.org" , David Mandelberg Subject: Re: [sidr] draft-ietf-sidr-bgpsec-protocol-13's security guarantees X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 01:12:28 -0000 > In the example with -- > A --> B --> C --> D -->, if B and C (the ones > that were signing but not verifying) return to the update to verify, > then they will realize that the update they last signed (for the > prefix) was invalid, and will propagate an alternate valid signed > announcement or send a withdrawal message to D. and all the packts will return to their origins with a loud swoosh and re-route correctly :) > At this point, B and C have taken their corrective action. not really. the internet is all about the data plane. the control plane is there to help the data plane. randy From nobody Wed Sep 16 07:38:47 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0611B3F4C for ; Wed, 16 Sep 2015 07:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham 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 6YyM-xABkbJG for ; Wed, 16 Sep 2015 07:38:44 -0700 (PDT) Received: from gateway20.websitewelcome.com (gateway20.websitewelcome.com [192.185.55.25]) (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 6D9351B3F47 for ; Wed, 16 Sep 2015 07:38:44 -0700 (PDT) Received: by gateway20.websitewelcome.com (Postfix, from userid 500) id E4F61E1EFD74; Wed, 16 Sep 2015 09:38:43 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway20.websitewelcome.com (Postfix) with ESMTP id D131CE1EFD42 for ; Wed, 16 Sep 2015 09:38:43 -0500 (CDT) Received: from [75.144.26.38] (port=53477 helo=[10.0.0.131]) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.85) (envelope-from ) id 1ZcDr9-000764-44; Wed, 16 Sep 2015 09:38:43 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 $1878.6$) From: Sean Turner In-Reply-To: <55CA4901.4010007@bbn.com> Date: Wed, 16 Sep 2015 07:38:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <555F436F.3080003@bbn.com> <2BF75857-6A5F-4260-B13B-0B9F6CE3FD98@ieca.com> <197E8AEA-D554-4DB4-885E-CFD55EF9E774@ripe.net> <55C4D7C8.4000401@bbn.com> <97B4FBD1-BCE6-4D37-BC0C-07A211347FBF@ieca.com> <55CA4901.4010007@bbn.com> To: Richard Hansen X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 75.144.26.38 X-Exim-ID: 1ZcDr9-000764-44 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.0.0.131]) [75.144.26.38]:53477 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: sidr wg list Subject: Re: [sidr] preventing SKI collisions X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 14:38:46 -0000 On Aug 11, 2015, at 12:12, Richard Hansen wrote: > Unfortunately no, with the disclaimer that I haven't really thought > about it in depth. Because of the challenge of accomplishing topic = #3, > I would like start with the much simpler topic #1. Note that I'm not > opposed to tackling #3, but the amount of work involved means that I'd > like to get topic #1, and possibly topic #2, out of the way first. >=20 Okay so I think we=92re in agreement here that we don=92t work on #3 = now, but I=92m also thinking that we should leave #1 and #2 alone for = now. If we think a SHA-1 hash for the RPKI=92s KIs are good enough = now, then it sounds like it's also good enough for BGPsec. It seems = really odd that we do something different in BGPsec than what is done in = the rest of the RPKI. So, I=92m proposing that: 1. We make no change to the SKI generation mechanism. 2. To make sure folks don=92t continue to go down this rathole I think = we should add the following to the security considerations, which is = copied from RFC 7093: While hash algorithms provide preimage resistance, second-preimage resistance, and collision resistance, none of these properties are needed for key identifiers. 3. We tackle the KI algorithm change we/if we re-open the RPKI PKI = profile. spt From nobody Wed Sep 16 07:42:40 2015 Return-Path: