[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed Up/Down protocol description
Rob,
We've now had the chance to read though your comments carefully
and talk about them in detail. Here's what we've come up with. Thanks
for the careful read through of the document - as you can see we've
got a lot from your review comments!
1. HTTP as the transport
------------------------
>> 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.
Yes, we had thought that the XML exchange could be readily implemented
levering off the existing HTTP code base if this , and there is still
the option of the potential application for channel security using
HTTPS as a simple uplift if channel security was considered to be a
useful functional attribute.
2. URL structure
----------------
> Doc says nothing about URL structure. Should it?
We don't believe so. The URL is the place you perform the POST
operation to. Addinging query arguments to the URL will not affect the
operation of this protocol (i.e. they are non-meaningful). The content
POSTed to this URL is "well formed" binary CMS (with content type of
"application/x-rpki")
3. MSG_REF processing
---------------------
>> 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.
The text you quote is indeed incorrect! It should read:
The request / response mechanism is assumed to be reliable, in that
requests will generate a matching response. The protocol supports
sequential operation, in that multiple requests will have an inferred
sequencing as specified by the ISP through the relative values of
the msg_ref attribute in each message. Messages will be processed by
the IR in order of increasing msg_ref values, and detected
out-of-order requests and duplicate requests will not be processed by
the IR, and will, instead, generate an error response. The algorithm to
support this processing is described below.
4. Checking Requirements
------------------------
> 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.
We've talked this though and think that the following sequence of
checks would work as a description of checking requirements:
1. Check that the CMS is well-formed
2. Check that the XML is well-formed
3. Verify the digital signature using the public key provided
in the certificate carried in the CMS
4. Check that the XML sender and rcipient attributes reference
a known client and this system respectively.
5. Validate the CMS-provided certificate using the Business PKI
that is associated with the sender
6. Use the XML msg_ref and CMS Signing_Time attribute values to
detect that this message is correctly in sequence
Errors in steps 1 through 5 would generate an HTTP 400 Bad Data response
An error in Step 6 would generate a well-formed protocol error response
as described in the msg-ref processing algorithm
The checks should generally be applied in the order specified, with the\
possible exception of steps 3 and 4.
5. Namespace URN
----------------
>> 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.
We're a little wary of using an nro.net namespace this week - it seems
to have gone out of fashion all of a sudden! We would like to propose
a URL drawn out of APNIC space that if ever pasted into a browser
leads to some generally useful documentation links. We'd like to
propose the URN: "http://www.apnic.net/specs/rescerts/up-down/";
6. msg_ref value sequence
-------------------------
>> 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.
Agreed - "The msg_ref value is a positive integer value in a strictly
monotonically increasing sequence" would be the wording I would add
here.
7. namespace and versioning
---------------------------
>> 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 version 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.
We've discussed this at some length, and come up with the following:
- propose to remove the version information from the content type
(leaving the content type of "aplication/x-rpki")
- propose to keep any version number out of the namespace identifier
- propose to restore the "version" attribute of the message element
and define its value as "1" for this specification.
- note that there may be a requirement for explicit version
negotiation in future versions of this protocol, but defer the
specification of any such negotiation until the next version
- allow implementations to accept any message, irrespective of the
version value as long as the recipient understands the namespace
and the recipient understands all elements and attributes that are
used in the message.
8. msg_ref handling algorithm
-----------------------------
>> The handling of the msg_ref values is as follows:
>> [...]
>
> 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.
thanks for the suggestion - we'll add the sentences and also
explicitly specify the msg_ref values as being positive integer
values.
9. msg-ref time interval values and algorithm review
----------------------------------------------------
>> 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.
We'll leave these values as is for the moment and see if there are
further review comments that would argue for a different setting of
these time interval thresholds.
> This algorithm description needs more eyeballs.
Agreed! Is this something that could be undertaken at the meetings to
be held at the NANOG venue?
10. Resource Class names and their use in XML
---------------------------------------------
>> 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.
>> 3.3.1 Certificate Issuance Request
>> [...]
>> 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.
>> 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.
>
> 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"/>
We're happy to go this way. For the Issuance Request, we'll add a
class_name attribute to the <request> element. For a Revocation
Request and Response, we'll use <key class_name="[Class name]"
ski="[g(ski)]"/>. We don't see any changes that need to be made to
the descriptive text, other than to go from "className" to
"class_name." CamelCase is an XML-ism Byron introduced when he put
his hand in the mix, and he admits that it is inconsistent with other
uses (!.
11. HEX spec
------------
>> 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?
http://www.w3.org/TR/xmlschema-2/#hexBinary
If we use XML Schema's data types (in this case, constructing an IPv6-
Address data type from the basic blocks of XML Schema's types) then it
is case insensitive with the canonical form being upper case.
This needs to be added to the spec.
12. Punting SneakerNet
----------------------
>> 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.
Agreed
>> status :
>> [...]
>> 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.
Agreed
>> 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.
Agreed
>> 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?
Agreed (in that is was for sneakernet, and it can disappear!)
13. Consistent syntax for resource_set_ attributes
--------------------------------------------------
>> 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?
I'll do the reference here
> Why are the last three optional? When should they be present, when
> should they not be present? Needs more explanation.
And noted - additional text will be added
14. req_resource_set semantics
------------------------------
>> 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.
Agreed
>> 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?
old text. Will go.
15. Certificate Revocation
--------------------------
> 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.
It is about certificate revocation, in that in attempting to get rid
of all material that uses a particular key, a set of certificates that
refer to the public part of that key need to be revoked. The term
"certificate revocation" is not used in the protocol, its just a
section heading in this text. Perhaps if more text is added to note
that individual certificates cannot be revoked upon request, but
instead a set of certificates that share a common subject's public key
can be revoked in a single reuqest?
16. Error Responses
------------------
>> 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.
The <wait> element is to be removed. So we are down from 4 to 3
We've had some lengthy discussions on element vs attribute, and what we
are proposing here is based on deferring to our in-house XML expertise.
It appears that there is a strong element of style involved here, and
evidently explicit elements are favoured.
> No description of status.
to be added.
> 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.
Again this has been a topic of discussion here, and there are proponents
that make the case that XML is indeed human readable text and that this is
a positive attribute.
I suppose that we could make this element optional for implementations
if you prefer. Would this be an acceptable way forward?
17. Registry of Error Codes
---------------------------
>> [[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.
ok, agreed.
regards,
GGM, Byron and Geoff
(Rob L has had today off!)
