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

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