Subject: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03

From: Sandra Murphy <[email-masked]>
Date: Fri, 6 Mar 2015 04:22:30 -0500

The authors of  The Resource Public Key Infrastructure (RPKI) to Router Protocol believe that the work is ready for a working grow last call.

This starts a last call for that draft.  You may find it at https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-03.

Please comment to the list whether you believe that this draft is ready for publication.  The wglc will be two weeks, ending on Friday, March 20.

--Sandy, speaking as one of the wg co-chairs

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 6 Mar 2015 11:04:26 +0100

Hi,

I read the document and it looks good to me, except for one clarification in section 5.10:
https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-03#section-5.10 <https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-03#section-5.10>

The IPv4 Prefix description (section 5.6) has the following, and the IPv6 text refers back to this:
> The lowest order bit of the Flags field is 1 for an announcement and
> 0 for a withdrawal.

I expect that announcement and withdrawal is signalled in a similar way for router keys? If so it would be good to make this explicit.

Tim

> On 06 Mar 2015, at 10:22, Sandra Murphy <[email-masked]> wrote:
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Randy Bush <[email-masked]>
Date: Fri, 06 Mar 2015 19:10:31 +0900

> I expect that announcement and withdrawal is signalled in a similar
> way for router keys? If so it would be good to make this explicit.

<doh>.  thanks

randy

---

From: David Mandelberg <[email-masked]>
Date: Tue, 17 Mar 2015 00:46:23 -0400

On 2015-03-06 05:22, Sandra Murphy wrote:
> Please comment to the list whether you believe that this draft is
> ready for publication.

I reviewed this draft. My substantive comments are below, and I'll send 
nits to the authors. Other than the below and the comment that Tim B 
sent to the list, I think the draft is ready for publication. (Note that 
while I have written a cache implementation of version 0 of this 
protocol, I have not yet written an implementation of version 1.)

Section 5 says "Fields with unspecified content MUST be zero on 
transmission and MAY be ignored on receipt" and Section 5.1 says "Fields 
shown as zero or reserved MUST be zero.  The value of such a field MUST 
be ignored on receipt." Are there three separate things (unspecified, 
zero, and reserved) to which these different rules apply? Or are these 
all the same thing, and the MAY in the first quote conflicts with the 
second MUST in the second quote?

The Router Key PDU (section 5.10) uses a fixed-size field for the SKI. 
What's the plan for algorithm agility, if the size of the SKI changes? 
if the size of the SKI does not change, but the algorithm does?

Section 7 adds the requirement that "A router MUST start each transport 
session by issuing either a Reset Query or a Serial Query." However, I 
don't see an additional requirement that the cache can't start sending 
PDUs (e.g., a Serial Notify) before it receives a Query from the router. 
Maybe there should be? Our current (version 0) implementation sends a 
Serial Notify whenever there is a new serial number, even if the router 
has not yet made any queries. If a version 1 router connects to our 
version 0 cache and we somehow manage to send a Serial Notify before the 
router is able to send a Query, what should the router do? Likewise, 
what should the router do if it receives any version 1 PDU before it has 
sent a Query?

What happens if version 1 is successfully negotiated, but a later PDU 
is sent (in either direction) with its version set to 0? Should the 
receiving side send an Error Report and disconnect? Likewise, what 
happens if version 0 is successfully negotiated, but a later PDU has a 
version of 1? Should the receiving side send an Error Report and 
disconnect? Even if the version 1 PDU is a Query (router to cache) and 
the cache supports version 1? I have no issue with disallowing 
re-negotiation of the protocol version, but I think it should be clearly 
specified that negotiation happens only at the beginning of a transport 
session.

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 17 Mar 2015 04:07:15 -0400

A reminder to everyone that this wglc ends Mar 20.

There have been a couple of detailed responses.  There should be more, in order to judge consensus to publish.

--Sandy, speaking as one of the wg co-chairs and chief nag

---

From: "George, Wes" <[email-masked]>
Date: Tue, 17 Mar 2015 14:29:34 -0400

nit:
If this is 6810bis, shouldn't it formally list 6810 in the
updates/obsoletes metadata?

Other comments:
Section 6 Expire interval - this seems out of step with the way that we've
done most things in RPKI, i.e. what to do with the information provided is
usually thought of as a matter of local policy. I realize that there is
increasing risk to keeping the data beyond the expiry time as it grows
more stale, but there isn't much justification for why this MUST NOT is
present. I think that perhaps the tradeoff between staleness and
everything failing back to unknown status is something that the operator
needs to weigh themselves. We could provide guidance that [MUST/SHOULD]
NOT keep data from a certain cache beyond expiry time *if* another cache
is available, but acknowledge that in some cases stale info may be more
desirable than nothing at all (unless that's not actually true and I'm
missing something...) This is discussed in the failover scenarios in the
bottom of section 10 (only keep data if you don't have a full set from
another cache) but figured I'd mention it in case we think there's some
tweaks necessary in the section 6 text.

Also -
Since we say in section 10 that it is permissible to hold data from
multiple caches, the doc appears to be missing guidance on what the router
side of RPKI-router should do in the case where there are multiple caches
that disagree with one another. It does say MUST NOT distinguish between
data sources when validating, but that may not cover this scenario. This
may be as simple as recommending that in the case where data from multiple
caches is held and specific entries conflict with one another, there
SHOULD be an odd number of caches so that there is basis for comparison to
determine which cache is out of sync or providing incorrect info. (i.e.
Have 3 so that you can go with the 2/3 that agree)

Thanks,

Wes

On 3/17/15, 4:07 AM, "Sandra Murphy" <[email-masked]> wrote:

>> The authors of  The Resource Public Key Infrastructure (RPKI) to Router
>>Protocol believe that the work is ready for a working grow last call.
>>
>> This starts a last call for that draft.  You may find it at
>>https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-03.
>>
>> Please comment to the list whether you believe that this draft is ready
>>for publication.  The wglc will be two weeks, ending on Friday, March 20.
>>

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: David Mandelberg <[email-masked]>
Date: Wed, 18 Mar 2015 23:10:14 -0400

On 2015-03-17 14:29, George, Wes wrote:
> This

Are you suggesting comparison of all the data from each single cache as 
an atomic entity, or comparison of individual IPvX and Router Key PDUs?

If the former, then I think that would work fine as long as a majority 
(or maybe even a plurality) of the caches has the exact same data. But 
what does the router do if this is not the case? If the caches all 
download from the RPKI at different times, then I would expect it to be 
common for no two caches to have the same data.

If the latter, then the semantics depend heavily on exactly how the 
comparison is done. Lets say a CA simultaneously issues one ROA for {AS 
65536, 10.0.0.0/8} and another for {AS 65537, 10.0.0.0/8}. Some of the 
caches see the publication point before both ROAs are issued; some see 
the pub point after both ROAs are issued and published. Can you 
guarantee that the voting mechanism will always result in either both 
ROA payloads, or neither, being used? (If a router ends up using one but 
not the other, then a previously unknown route becomes invalid.)

---

From: "George, Wes" <[email-masked]>
Date: Thu, 19 Mar 2015 08:58:43 -0400

>not the other, then a previously unknown route becomes invalid.)

WG] well, that is mainly why I brought up the concern. Voting comparisons
like this can be hard to do with this amount of data, so if it was our
intent to allow multiple full views, we need better guidance on how we
think it's most likely to actually work. I'm not sure we'd see enough
consistency between caches to benefit from atomic comparisons, so it may
be a matter of taking age and other things into account. Building or
adapting a voting algorithm seems like a lot of effort for what may well
be a corner case, but if we're going to allow retention of multiple
caches' data, we have to address the issue of how to handle disagreement
between caches. Unless perhaps this part of section 10 is just
poorly-worded and the intent was only ever to allow retention of other
cache's data to keep a quasi-complete view during a failover/resync, i.e.
As one entry is pulled from the new cache, its corresponding entries
[SHOULD/MUST] be purged from the other one(s), etc.

---

From: "Borchert, Oliver" <[email-masked]>
Date: Thu, 19 Mar 2015 17:06:37 +0000

I reviewed this draft and examining section 5.10 Router Key,
I noticed that the format/encoding on the wire of the key is not
specified. 
The required format/encoding of the key e.g. DER is needed to assure
a correct implementation and interoperability.

Oliver

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

---

From: David Mandelberg <[email-masked]>
Date: Tue, 24 Mar 2015 10:36:45 -0500

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?

---

From: "Borchert, Oliver" <[email-masked]>
Date: Tue, 24 Mar 2015 15:58:28 +0000

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