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

From: "Borchert, Oliver" <[email-masked]>
Date: Wed, 25 Mar 2015 21:13:44 +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" <[email-masked]> 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" <[email-masked]> 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
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/sidr
>
>_______________________________________________
>sidr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/sidr

---

From: David Mandelberg <[email-masked]>
Date: Tue, 31 Mar 2015 21:44:01 -0500

> And the client must resynch with the server.

If the router sends a serial query, yes I agree.

> Be an implementation issue.

After talking with you in Dallas, I agree that we should try to give 
implementors some leeway here. I still think there's an issue to address 
though. Here's the case I want to prevent:

1. Router has all the data for version 0, session X, serial Y.
2. Router upgrades to version 1, disconnects, reconnects, and sends a 
serial query with version = 1, session = X, and serial = Y.
3. Cache replies with all the changes from (1, X, Y) to (1, X, Y+1), 
instead of from (0, X, Y) to (1, X, Y+1).

As you pointed out in person, one way to avoid this is for the cache to 
give each router a different session ID and track which version is used 
by each router. Then the cache can respond in step 3 with the changes 
from (0, X, Y) to (1, X, Y+1). Another way to avoid this is the first 
part of what I originally suggested: effectively requiring the cache to 
respond with a cache reset in step 3. Or the second part of what I 
suggested: requiring the router to issue a reset query instead of a 
serial query in step 2. I'm having trouble coming up with *simple* text 
that prevents the issue while allowing any solution. If you can think of 
something, that would be great. Otherwise, I'd prefer to at least pick 
one of the solutions that does not require a cache to track its routers 
individually.

---

From: Randy Bush <[email-masked]>
Date: Tue, 31 Mar 2015 22:38:23 -0700

why are you trying to rescue the case where a router (or cache) upgrades
versions in the middle of a session?
  o upgrade should be very rare
  o reload is relatively cheap
  o and you are generating kinky corner cases to patch it

session reset.  the bloody router (or cache) will have reloaded anyway
and does not have the old state.

randy