IETF Logo Mail Archive

Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)

"Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov> Mon, 09 January 2017 05:41 UTC

Return-Path: <kotikalapudi.sriram@nist.gov>
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 C16F1129ADB; Sun, 8 Jan 2017 21:41:44 -0800 (PST)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 FNEO69FOrf_3; Sun, 8 Jan 2017 21:41:43 -0800 (PST)
Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0102.outbound.protection.outlook.com [23.103.201.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20696129AD6; Sun, 8 Jan 2017 21:41:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=X0UvsVUL7ST9Qp7ZvU2ZZv60fahPWzOa2akQUZ1ud7Q=; b=pKpKtOmMvWixmyt58wKawNA4RYFwsyEyzxXb0OVxysFwx+36CALLD0FtU6FVbXThVKmbbHjI6m+s4G/L1sAMMVlSkPWrkbXwp24Dc6oQ2/BSU8yMQ9SaFUHL6C78nprUSMLPyf/a8BClKoFHzxyVbN4+aNUbR4Gh92Rt4RsLw9o=
Received: from DM2PR09MB0446.namprd09.prod.outlook.com (10.161.252.145) by DM5PR09MB1433.namprd09.prod.outlook.com (10.173.171.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.7; Mon, 9 Jan 2017 05:41:41 +0000
Received: from DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) by DM2PR09MB0446.namprd09.prod.outlook.com ([10.161.252.145]) with mapi id 15.01.0817.015; Mon, 9 Jan 2017 05:41:40 +0000
From: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Montgomery, Douglas (Fed)" <dougm@nist.gov>, Russ Housley <housley@vigilsec.com>
Thread-Topic: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)
Thread-Index: AQHSZpHl3JK9Ep+Hw0SM2CHq7jfcT6EosxWAgAACfgCAAAebgIAADVwAgAAOQgCAAAG+AIAGyiWA
Date: Mon, 09 Jan 2017 05:41:40 +0000
Message-ID: <DM2PR09MB04468F57A38A20A58A33982584640@DM2PR09MB0446.namprd09.prod.outlook.com>
References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com> <B659D894-672F-4059-A001-5C4D1D602470@vigilsec.com> <3ae7d707-3229-2508-7aeb-2cd617aa97fd@cs.tcd.ie> <D492BBD6.6F422%dougm@nist.gov> <f306df7c-06a0-0662-93f4-5cb984a8eb0e@cs.tcd.ie> <D492D3B6.6F4BE%dougm@nist.gov>, <f1c2f28f-c889-ee6d-e670-e8f977492946@cs.tcd.ie>
In-Reply-To: <f1c2f28f-c889-ee6d-e670-e8f977492946@cs.tcd.ie>
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: [132.163.222.9]
x-microsoft-exchange-diagnostics: 1; DM5PR09MB1433; 7:wXnFz3Oh3ccqPhqdwyIYpAiHe3IbrrDyJnSMZVoZtfxkLbsDwR6bBzPmPwF2Pice4puxodF4mFSPkISJTLSpMWt+TgUBKmFdECz+TGtymE7rHPUomvaK5KbcRe3gb7N4oe5lq1N8Si/3RVEVaz+ouVoeOXzdIjkfnhqAAKbC5VEsXFqRzksGt7EK86iTUwNKumlGUgLrvwO6wUAVwizp+hu8CPqea6N3HBCoDij5b8B7DvPiGuey3e06XwFARrOfJWnjIabw9DwU7naXcBJ057jecmPaHFyMW9zxdL7eylzWyS014o8wcLZlamxwX+J1+pNy7QuEHUReEIzlJCdg6u5IZe8UsBNEY6SB7A/CkdS7ciWAu6ifWTVCv6BfWqjmLDfVxxL6+JGCFlxo9qVthxOHaqUgRvkqbHDypW21Qm66cbrf/7CqyanOWV18K2bEvQdOc96rn0gKBvqSQ4ZeqQ==
x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39410400002)(39850400002)(24454002)(199003)(51414003)(377454003)(189002)(99286003)(230783001)(3846002)(6116002)(189998001)(102836003)(74316002)(54906002)(305945005)(68736007)(7736002)(5001770100001)(97736004)(2950100002)(81156014)(8936002)(81166006)(3280700002)(38730400001)(229853002)(9686003)(8676002)(3660700001)(77096006)(106356001)(105586002)(54356999)(2900100001)(101416001)(86362001)(2906002)(106116001)(93886004)(4326007)(76176999)(50986999)(7696004)(33656002)(5660300001)(6436002)(66066001)(25786008)(122556002)(6506006)(55016002)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1433; H:DM2PR09MB0446.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-correlation-id: 475a723c-8ed3-412c-415c-08d438522fac
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR09MB1433;
x-microsoft-antispam-prvs: <DM5PR09MB1433395BF5FA06A3B5C7705684640@DM5PR09MB1433.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(32856632585715)(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:DM5PR09MB1433; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1433;
x-forefront-prvs: 0182DBBB05
received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2017 05:41:40.2532 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1433
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/UBd_miGdg9W0gczM7y9MdnJbN5o>
Cc: IESG <iesg@ietf.org>, IETF SIDR <sidr@ietf.org>
Subject: Re: [sidr] Stephen Farrell's Discuss on draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)
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: Mon, 09 Jan 2017 05:41:45 -0000

Stephen,

Please see response below.

>From: sidr <sidr-bounces@ietf.org> on behalf of Stephen Farrell <stephen.farrell@cs.tcd.ie>
>Sent: Wednesday, January 4, 2017 4:45 PM
>To: Montgomery, Douglas (Fed); Russ Housley

>Hiya,

>On 04/01/17 21:39, Montgomery, Douglas (Fed) wrote:
>> The RPKI validating caches *are* the relaying parties for BGPsec, they are
>> (a) designed to be run on a separate box than the router itself and (b)
>> their behavior WRT exchanges with RPKI repositories is independent of BGP
>> message processing by any of the routers that they serve.

>Sure. That makes sense. But where's it stated for BGPsec that
>the RP ought act that way?

I propose adding the following paragraph in Section 7. 
Please let me know if this would help resolve your concern/comment.  

The deployment structure, technologies and best 
practices concerning global RPKI data to reach routers 
(via local RPKI caches) are described in [RFC6810] 
[RFC7115] [I-D.ietf-sidr-bgpsec-ops] 
[I-D.-ietf-sidr-delta-protocol] [rsync]. 
For example, serial-number based incremental update 
mechanisms are used for efficient transfer of just the 
data records that have changed since last update [RFC6810]. 
Update notification file is used by relying parties (RPs) 
to discover whether any changes exist between the state of 
the global RPKI repository and the RP's cache 
[I-D.-ietf-sidr-delta-protocol]. The notification describes 
the location of the files containing the snapshot and 
incremental deltas which can be used by the RP to 
synchronize with the repository. Making use of these 
technologies and best practices results in enabling 
robustness, efficiency, and better security for the 
BGPsec routers and RPKI caches in terms of the flow 
of RPKI data from repositories to RPKI caches 
to routers (in distilled form). 

If you feel that the following sentence adds additional value, 
it can be added at the end:

In particular, by following these methods, security concerns 
related to possible correlation of RPKI data access 
and BGP update events are also mitigated.  

You may edit/suggesting any wording improvements. 
I look forward to your further guidance on this. 
Thank you.

Sriram

v2.23.0 | Report a Bug | By Email