Re: [sidr] WGLC for drained ft-ietf-sidr-rpki-rtr-rfc6810-bis-03

"Borchert, Oliver" <oliver.borchert@nist.gov> Wed, 25 March 2015 21:14 UTC

Return-Path: <oliver.borchert@nist.gov>
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 C4CD51A044F for <sidr@ietfa.amsl.com>; Wed, 25 Mar 2015 14:14:04 -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, 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 SYZ2VgzFVmfL for <sidr@ietfa.amsl.com>; Wed, 25 Mar 2015 14:14:02 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0770.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:770]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851991A007A for <sidr@ietf.org>; Wed, 25 Mar 2015 14:14:02 -0700 (PDT)
Received: from DM2PR09MB0286.namprd09.prod.outlook.com (25.160.96.143) by DM2PR09MB0287.namprd09.prod.outlook.com (25.160.96.144) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 25 Mar 2015 21:13:44 +0000
Received: from DM2PR09MB0286.namprd09.prod.outlook.com ([25.160.96.143]) by DM2PR09MB0286.namprd09.prod.outlook.com ([25.160.96.143]) with mapi id 15.01.0118.022; Wed, 25 Mar 2015 21:13:44 +0000
From: "Borchert, Oliver" <oliver.borchert@nist.gov>
To: "Borchert, Oliver" <oliver.borchert@nist.gov>, David Mandelberg <david@mandelberg.org>, "sidr@ietf.org" <sidr@ietf.org>
Thread-Topic: [sidr] WGLC for drained ft-ietf-sidr-rpki-rtr-rfc6810-bis-03
Thread-Index: AQHQZ0CTdT6ASHFRyUaxHdTkYjFfEA==
Date: Wed, 25 Mar 2015 21:13:44 +0000
Message-ID: <D13889F3.2237A%oliver.borchert@nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [129.6.218.31]
authentication-results: nist.gov; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0287;
x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(40224003)(51704005)(377454003)(24454002)(30584003)(479174004)(122556002)(102836002)(40100003)(230783001)(15975445007)(99286002)(2900100001)(92566002)(106116001)(77156002)(107886001)(2501003)(54356999)(50986999)(86362001)(87936001)(2656002)(46102003)(83506001)(19580395003)(19580405001)(66066001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0287; H:DM2PR09MB0286.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
x-microsoft-antispam-prvs: <DM2PR09MB0287D4996A0DF1EC30E76AA1980B0@DM2PR09MB0287.namprd09.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR09MB0287; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0287;
x-forefront-prvs: 052670E5A4
Content-Type: text/plain; charset="utf-8"
Content-ID: <EDB21A458F5A1444A1C3F6C966941BCC@namprd09.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2015 21:13:44.1560 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0287
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/vfXpU2Ttmf5rUGMdeiiNLRnNftg>
Subject: Re: [sidr] WGLC for drained ft-ietf-sidr-rpki-rtr-rfc6810-bis-03
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 25 Mar 2015 21:14:04 -0000

David,

A correction for my previous email, I mixed up session id and serial
number.
I think to keep it simple for version 0 - 1 switches and future changes, a
change
Within the session id and version id should trigger a “Cache Reset” by the
cache
And the client must resynch with the server.
And yes, wording in this matter might need to be added - but still it also
could
Be an implementation issue.

Oliver

-------------------------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238





On 3/24/15, 10:58 AM, "Borchert, Oliver" <oliver.borchert@nist.gov> wrote:

>Isn¹t this an implementation issue? The client either speaks 0 or 1. As
>long as the server
>keeps track of the version for the session IMHO it does not matter if the
>session id is 
>shared? The client doesn¹t know about it. Lets say one encounter a new key
>and this 
>Only triggers a PDU 9, the server sends send out the notification. The
>client can but must not
>React to it anyhow. If the client reacts, the server sends an end of
>update to a version 0
>session and all pdu 9 updates to a version 1 session.
>I don¹t see a needed wording here. Not yet but IŒm open for enlightenment.
>
>Oliver
>-------------------------------------------------------------
>Oliver Borchert, Computer Scientist
>National Institute of Standards and Technology
>(Phone) 301.975.4856 , (Fax) 301.975.6238
>
>
>
>
>
>On 3/24/15, 10:36 AM, "David Mandelberg" <david@mandelberg.org> wrote:
>
>>Rob and I were talking about rpki-rtr, and I came up with another
>>potential issue with switching between protocol versions. I don't see
>>any text about whether a single session (session id and serial numbers)
>>can be used for both version 0 and 1. If a router has a valid version 0
>>session, upgrades to version 1, and issues a serial query with the same
>>session id and serial number, it's unclear what the server should do.
>>Could we add text to the document saying that the cache MUST maintain a
>>separate session for each protocol version it supports, and a router
>>MUST NOT attempt to reuse session information across multiple protocol
>>versions?
>>
>>-- 
>>David Eric Mandelberg / dseomn
>>http://david.mandelberg.org/
>>
>>_______________________________________________
>>sidr mailing list
>>sidr@ietf.org
>>https://www.ietf.org/mailman/listinfo/sidr
>
>_______________________________________________
>sidr mailing list
>sidr@ietf.org
>https://www.ietf.org/mailman/listinfo/sidr