Subject: [drinks] Review of draft-ietf-drinks-spprov-07

From: Dean Willis <[email-masked]>
Date: Wed, 25 May 2011 14:27:40 -0500

As I seem to recall Sumanth asking me to do so, I've just done a read through of draft-ietf-drinks-spprov-07.

It's a pretty solid document with a couple of nits that may need fixing. I'm also thinking that the security considerations and related discussion around authentication and authorization issues are a bit light and are likely to draw fire from the IESG.

I'll discuss my points in the order I noted them while going through the document, since I'm too lazy to actually organize by priority or in any more meaningful way.

4.1/4.2 NIT: We have some inconsistent capitalization oddities relating to words like "client", "server", "request" and "response", which are sometimes capitalized and sometimes aren't. There may be some sort of not-obvious--to-me rule in play about where they are being used as proper nouns vs. ordinary nouns, but it was a bit distracting and is likely to get changed by the RFC editor anyhow. I suggest quoting the word in its definition, then just using lower case everywhere else: For example, a "special term" may be defined in the text, but once it has been so defined, it's a just a special term.

4.4 Discusses authentication, which section 3.1 says is mostly out of scope for this document. However, there are some subtleties that it seems like the core spprov document needs to think about.  Is there a requirement for selective authorization? Given that SPPP intro and 3.2 seems to describe a registry as being provisioned by multiple SSPs, this could be important. Do we need  the request to model to 1) carry a subset specifier, or 2) provision selective access capabilities? Do we need the response model to discuss authorization failures in a useful way, for example saying "This part of your request failed, but that part would have succeeded?"  Indeed, spprov 4.4 talks about "authentication of the Client by the Server is expected to be used to identify and further authorize the Client to certain resources on the Server." Does the protocol have a need to allow a client to specify which other clients can change the data it submitted?

What is the relationship, if any, of the of orgId data element to authentication and authorization?

4.5  Confidentiality and Integrity. Requirement for confidentiality and integrity protection is good, but "by providing encryption capabilities" is an unsatisfying follow-on, either insufficient to assure the requirements, or restrictive of techniques that might alternately assure confidentiality and integrity protection. Easiest fix is to truncate the sentence short of the quoted text. EKR has many times told me that encryption is not a magic hammer and that, in a requirements sentence, it's better to declare that which must be protected than to claim everything is fixed by encryption.

Related to both 4.4 and 4.5 as well as section 9 "Security Consideration", we really haven't done our homework with respect to RFC 3552 yet. We need a more detailed deployment and threat model. For example, what are the possible consequences of a fraudulent route insertion? Conflicting route submissions by different parties? Route disclosures? For how long do we think that a given message will require confidentiality (as this influences requirements on key size and algorithm)?

4.8/4.9 deal with request/response correlation and acknowledgement. The use cases discussed a commit/rollback requirement wherein related sub-requests can be expected to either fail or succeed as a group. Do we adequately address reporting of the failed sub-request? Do we need to?
  
4.10 Mandatory Transport  says "As of this writing of this revision, one transport protocol proposal has been provided in [I-D.ietf-drinks-sppp-over-soap]. This section will define a mandatory transport protocol to be compliant with this RFC."

However, at this time, this section does not go on to define a mandatory transport protocol. So there's something wrong with section 4.10. 

Sections 5-7 discuss protocol data structures that appear to be defined in a formal language (XMLSchema), but I haven't noticed anywhere in section 5 where this is stated. Are the schema entries in this sections simply excerpts from Section 11? Perhaps an additional introductory line under 5 could clear this up. Note that 6.8 and some other sections with this sort of text explicitly invoke XSD. Do we need a reference to XSD? I validated the XML in section 11, but didn't check every snippet in 5-7. has anybody done this? The XML gurus are rather unforgiving about invalid XML.

5.2 Response Codes and Messages: Are we going to need an IANA registry for response codes? If so, we should define one under IANA Considerations.

6.1 DestGrpType discusses server-defined date/time values.Do we need further discussion on time zones, relative vs. absolute times, and what these time values mean to clients? This question persists through several subsequent extensions of BasicObjType (6.5, 6.7, 6.9, 6.13). Examples in section 7 are using Z-time. What are the consequences, if any, of time-base mismatches? Do we need to say anything about this?

6.3 p4: s/Destionation/Destination/, several times.

6.9/6.10 I'm befuddled about the functionality of putting peeringOrg elements into a Route Group Offer operation.  Maybe I'm just being normally dense. Are we trying to say that the registry should accept the route group because the listed peeringOrgs already have? Is this subject to some sort of "bullshit attack" like the chain-letter spam that claims the reported virus was validated by Microsoft?

Section 7: Anybody validated the XML herein? It looks good to my Mark 1 eyeballs, but they're a bit out of date.

Section 9, Security Considerations. See my earlier rant. If the IESG lets the doc through without more flesh here, I'll buy an adequate number of rounds for everybody in the working group.

Additionally,  Mickael had some questions on the list, some of which seem to require modifications to the text. I'd not like to forget about those.

--
Dean

---

From: David Schwartz <[email-masked]>
Date: Thu, 26 May 2011 11:23:45 +0300

Hi Dean... some comments inline...

> 4.4 Discusses authentication, which section 3.1 says is mostly out of scope for this document. However, there are some subtleties that it seems like the core spprov document needs to think about.…

DS: This topic does indeed (imho) warrant additional discussion. While the current thought process is that this topic is implementation specific, after actually trying to implement this stuff and getting stuck with the now absent rarID, I think this should be revisited.
> Sections 5-7 discuss protocol data structures that appear to be defined in a formal language (XMLSchema), but I haven't noticed anywhere in section 5 where this is stated. Are the schema entries in…

DS: Yes, this is a good point. As much of the original work was culled from the ESPP work done at CableLabs, I suspect that some parts of the XSD made it over to SPPP without their accompanying textual descriptions. It should be fairly easy I would think to regenerate the required text in SPPP for these constructs.
> 6.1 DestGrpType discusses server-defined date/time values.Do we need further discussion on time zones, relative vs. absolute times, and what these time values mean to clients? This question persist…

DS: I have always been a fan of just using UTC
> 6.9/6.10 I'm befuddled about the functionality of putting peeringOrg elements into a Route Group Offer operation.  Maybe I'm just being normally dense. Are we trying to say that the registry should…

DS: The idea behind the peeringOrgs is the notion that I may want to share information about a route with some and not with others. The idea behind sourceID is the notion that I may want to give different egress points to different requesting parties. Both these functionality are quite important for managing peering relationships. The one comment I have on this is that while I completely understand the sourceID binding to the RouteGroup, I think the peeringOrgs should actually be tied to the DestinationGroup and not the RouteGroup.
> _______________________________________________
> drinks mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/drinks

---

From: Dean Willis <[email-masked]>
Date: Thu, 26 May 2011 09:33:24 -0500

> DS: I have always been a fan of just using UTC

Can we include UTC in the specification?

What happens if the client and the server have wildly different ideas of the current value of UTC? Does anything break?

> DS: The idea behind the peeringOrgs is the notion that I may want to share information about a route with some and not with others. The idea behind sourceID is the notion that I may want to give di…

Well, let's get that discussed on this list, then.

If I understand what you said, then the peeringOrg element dictates to whom one might make an object (DestinationGroup or RouteGroup, TBD) available.

This means it interacts with the authentication/authorization model in a way that the current protocol spec does not elucidate, and probably should.

--
Dean