[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed Up/Down protocol description
Some proofreading notes. Text not relevant to these notes elided for
brevity.
> The underlying transport for this protocol is HTTP. The ISP initiates an
> HTTP POST with content type of application/x-rpki-version1, with the
> message as the body. The IR's response will similarly be the body of the
> response with a content type of application/x-rpki-version1.
So we're standardizing on HTTP. I don't have a problem with that,
it's what I was going to use, but it's a recent thing for this spec.
Doc says nothing about URL structure. Should it?
> The request / response mechanism is assumed to be reliable, in that
> queued requests will generate a matching response, and sequential, in
> that multiple requests will be ordered and processed by the IR in the
> order that they were sent by the ISP. Detected out-of-order requests and
> duplicate requests will not be processed by the ISP and will instead
> generate an error response.
Am not sure protocol as documented supports all of this.
Duplicate/replay protection we have. Out-of-order detection we only
sort of have, because nothing requires sequential msg_ref values.
I seem to recall some discussion in the 2nd floor lobby in Tallinn
about what the checking requirements here really are. This morphed
into a discussion of replay protection; I'm reasonably happy with
where the replay protection discussion went, but suspect we may have
neglected to pop the stack and finish the original discussion.
> 3.1 Common Message format
>
> <message xmlns="urn:uuid:f345d68f-225c-48b7-8abd-8c2373c68f4d"
> sender="sender name"
> recipient = "recipient name"
> msg_ref="reference"
> type="message type">
Please find a better URN. Personally, I would be fine with
http://urn.nro.org/wombat.rpki.1; don't care all that much but this
UUID thing a bit too whacky for me.
> msg_ref :
> value is set by the sender when generating a query. The
> corresponding response message contains the same msg_ref value. A
> sender must ensure that different msg_refs are used for each query,
> and the receiver must ensure that duplicate requests are detected
> and rejected.
A few paragraphs further down it becomes clear that this has to be a
positive decimal number, and that it has to be monotonically
increasing within the reset_interval of the replay protection
mechanism. Should say at least some of that here.
> The namespace supplied in this document is a placeholder namespace,
> pending a permanent home being found for this document. The namespace
> acts as a version number. Incompatible changes to this specification
> will result in a new namespace being used. Backwards compatible changes,
> that is, the addition of optional elements or attributes, will not cause
> a new namespace to be used. Conforming parsers MUST ignore all elements
> and attributes that are not a part of this document.
The namespace is not a verion number, and has different properties.
If the namespace doesn't match, all you know is that you're clueless.
If a version number is higher than you expected, you may (depending on
the protocol definition) know that you're allowed to continue doing
what you understand.
I'm not really opposed to using a namespace instead of a version
number, but they don't work the same way and you might want to think
about which properties we really want the compatability detection
mechanism to have.
> The handling of the msg_ref values is as follows:
>
> The algorithm is intended to provide for protection against replay
> attacks (duplicate message detection) while not holding a large amount
> of state on the server or client. This algorithm places a time bound on
> the duplicate detection capability.
>
> Duplicate message detection relies on the server (IR) and client (ISP)
> both running an absolute time clock (i.e. some clock that can produce a
> date and time value to a level of granularity of seconds or higher).
>
> The server holds per-client stored last_msg_ref values (initially set
> to 0), and per-client stored last_msg_time values (initially set to 0)
> and two statically configured time interval values, the reset_interval
> value and the allowed_clock_skew_interval value.
>
> The client holds a msg_ref counter which is incremented by one for each
> sent message.
>
> The algorithm is:
>
> * The client passes its clock value to the server via the Signing
> Time attribute of the CMS message wrapper (see above).
>
> * If the server detects that the received Signing Time is outside
> of the server's clock +/- allowed_clock_skew_interval, then the
> message is rejected with a time error. The server's clock value
> is communicated to the client via the Signing Time attribute of
> the CMS message wrapper in the response.
>
> * If the last_msg_time for this client is 0, or if the
> last_msg_time is less than the server's time of day -
> reset_interval, then the last_msg_ref for this client is set to
> the msg_ref value in this message, and the message is accepted
> for processing.
>
> * If the msg_ref value is less than or equal to the last_msg_ref
> for this client, then the message is rejected with an "incorrect
> msg_ref" code, and the server's value for last_msg_ref is placed
> in the last_msg_processed attribute of the error response.
>
> * Otherwise the local last_msg_ref value is set to the msg_ref
> value of the message, and the message is accepted for processing.
I think this algorithm is ok. I might nitpick about values the client
is allowed to send as msg_ref, perhaps client should only send
positive values since server is remembering zero as starting point.
A bit more explanation of each step might help, on the order of one
sentence per step explaining in conceptual terms what the test is
about so that the reader can more easily see that the test as
described fulfills that function.
> The proposed value for allowed_clock_skew_interval is 60 (?) seconds
>
> The proposed value for reset_interval is 600 (?) seconds
I haven't figured out yet whether these values are insanely small or
just right. allowed_clock-skew_interval does seem kind of small given
that it's both time between signature and receipt and also clock skew
between client and server. Dunno about reset_interval, initial
reaction was that it was much too small but in the context of this
replay protection algorithm it may be ok.
This algorithm description needs more eyeballs.
> name :
> value is the issuer-assigned name of the issuer's Resource Class.
Terminology gets a little whacky here. "issuer" is a certificate
relationship. I think you mean "parent-assigned" or "IR-assigned".
Similarly for several more uses of "issuer" that follow (but not all,
as some really do talk about certificates). My preferred terminology
is "parent" and "child", YMMV.
Also note that class names in -responses- in this protocol are always
attributes, while in -requests- the post-Byron version has them as
element text. This seems whacky to me, I'd just make them attributes
throughout, as, regardless of one's XML religion, class names in this
protocol pretty much have to be the same kind of data in requests as
they are in responses in XML structure terms. RobK made a similar
point about an earlier version of this text.
> resource_set_ipv6 :
> in the context of a class, this is the set of IPv6 addresses that
> the IR has allocated to the ISP within the scope of this Resource
> Class. The value is presented in ascii as a comma-separated list of
> elements. Each element is either an address prefix using the
> notiation of /mask length, or a range specified as low and high
> range values in hex nibble notation with a hyphen delimiter.
> Trailing zero nibbles are truncated and represented by '::'. The
> list is presented in canonical order, as described in RFC3779. The
> hex nibble sequence notation is without leading zeros, and the list
> contains no whitespace or punctuation other than the colon, forward
> slash, hyphen and comma. (e.g.
> resource_set_ipv6="2003:A::/32,2001:7ABC::-2001:7FFF") If there are
> no IPv6 addresses in this Resource Class the empty set will be
> represented by a null string value ("") for this attribute.
Is the hex case-sensitive? Is there a preferred case?
> Each certificate element describes the most recently issued currently
> certificate for the ISP for each active ISP key pair. A "current"
> certificate is a non-expired, non-revoked certificate. If a current
> certificate exists then the cert_url, cert_ski, cert_aki, cert_serial,
> resource_set_as, resource_set_ipv4, resource_set_ipv6, and [certificate]
> will be present. If no current certificate has been issued, but an
> issuance is pending, then these fields will be omitted and and the status
> value will be "issuance-pending". If no issuance is pending then no
> certificate element will be included in the response.
The second to last sentence (and perhaps the last) can probably be
struck now that we've punted sneakernet out of the protocol.
> resource_set_as :
> in this context, the set of AS numbers that are contained in the
> resource extension of this certificate.
>
> resource_set_ipv4 :
> in this context, the set of IPv4 addresses that are contained in
> the resource extension of this certificate.
>
> resource_set_ipv6 :
> in this context, the set of IPv6 addresses that are contained in
> the resource extension of this certificate.
>
> req_resource_set_as :
> (OPTIONAL) the set of AS numbers that were specified in the
> corresponding original certificate request that define the maximal
> requested span of the certified AS number set.
>
> req_resource_set_ipv4 :
> (OPTIONAL) the set of IPv4 addresses that were specified in the
> corresponding original certificate request that define the maximal
> requested span of the certified IPv4 address set.
>
> req_resource_set_ipv6 :
> (OPTIONAL) the set of IPv6 addresses that were specified in the
> corresponding original certificate request that define the maximal
> requested span of the certified IPv6 address set.
There should be a note (somewhere) that these six all follow the same
syntax as the previous attributes of this form. Perhaps the detailed
syntax should be pulled to a separate section so that others can
reference it?
Why are the last three optional? When should they be present, when
should they not be present? Needs more explanation.
> status :
> The value "undersize" indicates that the certificate does not
> encompass all resources allocated to the ISP within this class.
> The value "match" indicates that the certificate spans all
> currently ISP-allocated resources in this class. The value
> "oversize" indicates that the certificate spans more than the
> currently ISP-allocated resources in this class. In the case that a
> specific set of number resources were specified in the original
> certificate request (as indicated by the presence of the
> req_resource_set-* attributes in the response), then the comparison
> status value refers to a comparison between the certified resource
> set and the intersection of the original requested resource set and
> the current ISP-allocated resource set. The value "issuance-
> pending" reflects the situation a certificate is in the process of
> being issued, but that this operation has not been undertaken as
> yet by the issuer (due to an asynchronous key signing engine in
> operation).
Last sentence can go away, sneakernet again.
> 3.3.1 Certificate Issuance Request
>
> type="issue"
>
>
> Payload:
>
> <className>[Class name]</className>
> <request
> req_resource_set_as="as resource set"
> req_resource_set_ipv4="ipv4 resource set"
> req_resource_set_ipv6="ipv6 resource set">
> [Certificate request]
> </request>
See previous comment on class names in requests. I'd just make
class_name an attribute of <request/> here.
> If any of req_resource_set_* attributes are specified in the request,
> then any missing attributes are to be interpreted as specifying the empty
> set of the corresponding resource type. The requested resource set values
> are held as a local record by the Issuer against the Resource Class and
> the Subject's public key. Any subsequent Certificate Issuance Requests
> that specify the same Resource Class and the same Subject's public key
> will (re)set the Issuer's local record of the requested resource sets to
> the most recently specified values.
This seems to miss one of the features that our original definition of
these attributes had: we could give an explicit list of resources, we
could say "no resources", and we could say "all available resources".
As written above, if any of these attributes are specified, the only
way to get all available resources of the other two kinds is enumerate
them explicitly. This seems wrong. I'd bring back the previous
behavior where absence of the attribute meant "all available", and one
specified "none" via an attribute with an explicit emtpy string.
> The issued certificate has a resource extension that fully covers the
> ISP's resources in this resource class.
This does not account for subsetting. Old text?
> If asynchronous key signing is being used then this request will generate
> a response with the most recently issued certificate and a status
> response of "issuance-pending".
More sneakernet text that can be removed.
> 3.4 Certificate Revocation
>
>
> 3.4.1 Certificate Revocation Request
>
> type="revoke"
>
>
> Payload:
>
> <className>[Class name]</className>
> <ski>[g(ski)]</ski>
Same problem as above with class names as elements in requests.
But I have another issue with this section and the corresponding
response section: this isn't really about -certificate- revocation,
it's about -key- revocation. Well, revocation isn't quite the right
word either, but I can't think of a better one offhand.
Anyway, I'd combine these into payload:
<key class_name="foo" ski="bar"/>
> 3.4.2 Certificate Revocation Response
>
> type="revoke_response"
>
>
> Payload:
>
> <className>[Class name]</className>
> <ski>[g(ski)]</ski>
Now here we have classnames in elements in a response. I detect a
certain lack of consistancy. :)
Please pick a single scheme and stick to it in all requests and all
responses. I'd prefer attributes over elements for this but I don't
really care so long as it's consistant.
Assuming elements, I'd use the same payload:
<key class_name="foo" ski="bar"/>
> 3.5 Request-Not-Performed Response
>
> type="error_response"
>
>
> Payload:
>
> <status>[Code]</status>
> <wait>[Seconds]</wait>
> <last_msg_processed>[msg_ref_value]</last_msg_processed>
> <description xml:lang="en-US">[Readable text]</description>
More element text vs attribute fun.
> wait :
> (OPTIONAL) parameter indicating the responder's estimate of the
> amount of time to wait before a transient error condition has
> cleared and the request can be repeated.
I -think- wait was for sneakernet, can it go away now?
>
> last_msg_processed :
> parameter indicating the responder's last processed msg_ref value.
> This element MUST be present when an "incorrect msg_ref" status
> code is used. It MUST NOT be present in all other cases.
No description of status.
No description of description, but in this case I would really prefer
just to get rid of description entirely. "Mail not delivered: not a
typewriter".
> If the HTTP request that triggered this error response includes an
> Accept-Language header as defined in section 14.4 of the HTTP/1.1
> specification [RFC2616] then the server will make a best effort to
> include a second description element using the highest ranked preferred
> language of the client. The en-US description will always be included.
Thank you for providing such a nice example of -why- I do not want the
description. Think protocol elements, not human readable text.
> [[A registry of defined error codes appears to be appropriate to reference
> here.]]
Ahem. Try
A registry of defined error codes MUST appear here.
That is: the error code registry is part of the specification. It's
ok for it to grow as we discover more errors, but it's protocol.
