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

[Rob Austein <[e-mail]>]

[Finally addressing last call comments...sorry for the delay, the
 other part of my day job has been taking up all of my time for months]

At Tue, 17 Mar 2015 00:46:23 -0400, David Mandelberg wrote:
> 
> 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?

Good catch.  There shouldn't be any unspecified fields, and we used
"zero" or "reserved - zero" interchangeably, with most of the
variation having to do with column widths in the PDU diagrams.

The version I will push out as soon as I've addressed all the WGLC
comments does not refer to "unspecified" fields, and uses "zero" to
mark all of the reserved zeroed fields.

The business of requiring reserved fields to be zero on transmission
and ignored on receipt is an idea we stole from RIPv2.  It's probably
not strictly necessary, since every PDU carries an explicit version
number, but it's harmless and makes the specification a bit more
robust the next time somebody finds something we specified badly.

I split the difference between MAY and MUST, yielding "SHOULD be
ignored on receipt."

> 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?

I'm gonna weasel on this one and say

a) A SKI is a SKI and it's none of this protocol's business how it's
   calculated, so we don't care about algorithm changes per se here,
   only about the length; and

b) If and when the SKI length changes, we redesign the PDU and bump
   the version number.

The alternative would be to add a SKI-Length field or some such,
either in the reserved ("zero") field just after the flags field, or
just after the PDU length field.

> 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?

Good catch.  I think the correct answer would be for the router to
ignore wrong-version Serial Notify PDUs received before the initial
version negotiation has completed.

In the current protocol, Serial Notify is the only unsolicited PDU
type, the only thing the router is required to do with that PDU is
refrain from crashing (solely) because of receiving it, and the only
other thing the router would ordinarily do with it would be issue the
Reset Query or Serial Query it's in the process of issuing anyway as
part of the version negotiation.  So absolving the router from the
requirement to break the session due to the version mismatch doesn't
lose us anything except an unintended self-DoS.

> 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.

I was going to say "just send an Error Report and disconnect", but it
looks like we'll need to add another error code to report this
properly ("Unsupported Protocol Version" isn't right here).

I'll add something to the version negotiation discussion stating that
this only happens during startup.