Last Call Review of draft-ietf-speermint-architecture-
review-ietf-speermint-architecture-secdir-lc-mundy-2011-02-07-00

Request Review of draft-ietf-speermint-architecture
Requested rev. no specific revision (document currently at 19)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-02-01
Requested 2011-01-17
Authors Jason Livingood, Daryl Malas
Draft last updated 2011-02-07
Completed reviews Secdir Last Call review of -?? by Russ Mundy
Assignment Reviewer Russ Mundy
State Completed
Review review-ietf-speermint-architecture-secdir-lc-mundy-2011-02-07
Review completed: 2011-02-07

Review
review-ietf-speermint-architecture-secdir-lc-mundy-2011-02-07

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

Since this review is for the architecture document, I needed to refer to the other drafts and RFCs from the WG to complete this review and I want to compliment the speermint WG for producing a cohesive set of documents.

A perhaps minor criticism is that the architecture document seems to have a narrower technology focus than other documents that are normative references, e.g., voipthreats, usecases, requirements.  Particularly after trying to determine the basic intent of the Security Considerations section (9), it appears as though this architecture document is focused on just the interconnection between two SIP Service Providers (SSP) while some of the normative references provide much more of an end-to-end description of the technology. Since this document has "architecture" in it's name but a somewhat narrower technology scope than some of it's normative references, it would seem to be useful to clearly state this in the introduction (or elsewhere) in the document.

Security Considerations specific comments: I do have concerns with the specifics of the Security Considerations section, in particular, I don't really understand the basic intent of what the two main paragraphs are trying to say.

- The basic meaning of when encryption should be used in the first paragraph is awkward and not clear (perhaps it's a compromise wording from the WG but that won't matter later) - I can read the wording several different ways which would result in very different inferences about when cryptography should actually be used, e.g.,:

- - "cryptographic-based security" should be used for all cases unless the connection is protected by physical security;

- - if there is not physical security between the peering providers, the use of "cryptographic-based security" is suggested/recommended;

- - use of "cryptographic-based security" is optional in all situations;

- - intended use of "cryptographic-based security" is different than any of the above.

Suggested solution: It seems to me like there should be some specific references to the appropriate sections of the voipthreats & requirements documents - this should not be a problem since they are normative references and will need to be published more or less at the same time.


- The second paragraph of the section seems to be saying that the WG believes that additional methods of peering need to be standardized (which seems fine) but it's rather unclear what the "maintain a consistent approach" is supposed to be consistent with especially since the security requirements of the previous paragraph are unclear.

Suggested solution: If clear and reasonably specific requirements can be identified for the previous paragraph then it seems like these (or equivalent requirements) can be applied to future standards for peering.


Other (basically editorial) Comments:

- In Section 4, the term "Session Border Controller" is not defined in RFC5486 or this document - it seems like a definition should be included.

- In Section 4, the first three bullet points would have "function function" if the acronyms were spelled out - this might be okay but some people view it as incorrect.

- In the fourth bullet of Section 4, it's not clear what "can communicate" means - is this a restrictive statement, does it mean that only the left-most function can initiate an exchange or something else altogether.  It seems like a clarification is in order.

- In Section 5.1.2.2, the term "carrier-of-record" is used.  The term is not defined or used elsewhere and seems to be important to the proper functioning of the procedure.  A clarification would seem to be in order.

- In Section 5.1.3.2, IPSec is mentioned in the originating procedures.  There is no corresponding mention in the target procedures section which seems to be an omission that should be corrected.  


Russ Mundy