Re: [secdir] secdir Review of draft-ietf-speermint-architecture-17

["Livingood, Jason" <[e-mail]>]

Russ - Thanks for performing a review of this document. The changes you have suggested will be made in a -18 update when I'm cleared to do so by my AD (Gonzalo). Please see my responses inline below to each specific item for the details.

Regards
Jason

-------- Original Message --------
Subject: secdir Review of draft-ietf-speermint-architecture-17
Date: Thu, 3 Feb 2011 01:06:22 +0100
From: Russ Mundy <[e-mail]<mailto:[e-mail]>>
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
CC: [e-mail]<mailto:[e-mail]>
<[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
<[e-mail]<mailto:[e-mail]>>, Russ Mundy <[e-mail]<mailto:[e-mail]>>


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.

[JL] I can see how this is the case. Based on your feedback, I plan to change it to this:
10.  Security Considerations

The level (or types) of security mechanisms implemented between peering providers is in practice dependent upon on the underlying physical security of SSP connections. This means, as noted in Section 6.1.3.3<http://xml.resource.org/cgi-bin/xml2rfc.cgi#Co-Location>, whether peering equipment is in a secure facility or not may bear on other types of security mechanisms which may be appropriate. Thus, if two SSPs peered across public Internet links, they are likely to use IPSec or TLS since the link between the two domains should be considered untrusted.

Many detailed and highly relevant security requirements for SPEERMINT have been documented in Section 5 of [I‑D.ietf‑speermint‑requirements]<http://xml.resource.org/cgi-bin/xml2rfc.cgi#I-D.ietf-speermint-requirements>. As a result, that document should be considered required reading.

Additional and important security considerations have been documented separately in [I‑D.ietf‑speermint‑voipthreats]<http://xml.resource.org/cgi-bin/xml2rfc.cgi#I-D.ietf-speermint-voipthreats>. This document describes the many relevant security threats to SPEERMINT, as well the relevant countermeasures and security protections which are recommended to combat any potential threats or other risks. This includes a wide range of detailed threats in Section 2 of [I‑D.ietf‑speermint‑voipthreats]<http://xml.resource.org/cgi-bin/xml2rfc.cgi#I-D.ietf-speermint-voipthreats>. It also includes key requirements in Section 3.1 of[I‑D.ietf‑speermint‑voipthreats]<http://xml.resource.org/cgi-bin/xml2rfc.cgi#I-D.ietf-speermint-voipthreats>, such as the requirement for the LUF and LRF to support mutual authentication for queries, among other requirements which are related to [I‑D.ietf‑speermint‑requirements]<http://xml.resource.org/cgi-bin/xml2rfc.cgi#I-D.ietf-speermint-requirements>. Section 3.2 of [I‑D.ietf‑speermint‑voipthreats]<http://xml.resource.org/cgi-bin/xml2rfc.cgi#I-D.ietf-speermint-voipthreats> explains how to meet these security requirements, and then Section 4 explores a wide range of suggested countermeasures.

- 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.

[JL] That seems to have been old text arguing for a separate security threats document, which we now have, so I removed it as written above.

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.

[JL] Another reviewer made the same point, so we created a new section 2 on terminology. We address this now:

2.1.  Session Border Controller (SBC)
A Session Border Controller (SBC) is referred to in Section 5<http://xml.resource.org/cgi-bin/xml2rfc.cgi#Relationships%20Between%20Functions/Elements>. An SBC can contain a Signaling Function (SF), Signaling Path Border Element (SBE) and Data Path Border Element (DBE), and may perform the Look-Up Function (LUF) and Location Routing Function (LRF) functions, as described in Section 3<http://xml.resource.org/cgi-bin/xml2rfc.cgi#Reference%20Architecture>. Whether the SBC performs one or more of these functions is generally speaking dependent upon how a SIP Service Provider (SSP) configures such a network element. In addition, requirements for an SBC can be found in [RFC5853]<http://xml.resource.org/cgi-bin/xml2rfc.cgi#RFC5853>.

- 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.

[JL] Already fixed. It now reads:
5.  Relationships Between Functions/Elements

Please also refer to Figure 1<http://xml.resource.org/cgi-bin/xml2rfc.cgi#ref_arc>.

  *   An SBE can contain a Signaling Function (SF).
  *   An SF can perform a Look-Up Function (LUF) and Location Routing Function (LRF).
  *   As an additional consideration, a Session Border Controller, can contain an SF, SBE and DBE, and may act as both an LUF and LRF.
  *   The following functions may communicate as follows in an example SSP network, depending upon various real-world implementations:
     *   SF may communicate with LUF, LRF, SBE and SF
     *   LUF may communicate with SF and SBE
     *   LRF may communicate with SF and SBE

- 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.

[JL] Clarified above

- 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.

[JL] Agree, and we also added this to the new terminology section:
2.2.  Carrier-of-Record

A carrier-of-record, as used in Section 6.1.2.2<http://xml.resource.org/cgi-bin/xml2rfc.cgi#Routing%20Table>, is defined in [RFC5067]<http://xml.resource.org/cgi-bin/xml2rfc.cgi#RFC5067>. That document describes the term to refer to the entity having discretion over the domain and zone content and acting as the registrant for a telephone number, as represented in ENUM. This can be:

  *   the Service Provider to which the E.164 number was allocated for end user assignment, whether by the National Regulatory Authority (NRA) or the International Telecommunication Union (ITU), for instance, a code under "International Networks" (+882) or "Universal Personal Telecommunications (UPT)" (+878) or,
  *   if the number is ported, the service provider to which the number was ported, or
  *   where numbers are assigned directly to end users, the service provider that the end user number assignee has chosen to provide a Public Switched Telephone Network/Public Land Mobile Network (PSTN/ PLMN) point-of-interconnect for the number.

It is understood that the definition of carrier-of-record within a given jurisdiction is subject to modification by national authorities.

- 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.

[JL] Yup.  We added a line to the relevant section to address this and refer back to the IPSec section.

6.2.1.  TLS

The section defines the usage of TLS between two SSPs [RFC5246]<http://xml.resource.org/cgi-bin/xml2rfc.cgi#RFC5246> [RFC5746]<http://xml.resource.org/cgi-bin/xml2rfc.cgi#RFC5746> [RFC5878]<http://xml.resource.org/cgi-bin/xml2rfc.cgi#RFC5878>. When the receiving SSP receives a TLS client hello, it responds with its certificate. The Target SSP certificate should be valid and rooted in a well-known certificate authority. The procedures to authenticate the SSP's originating domain are specified in [RFC5922]<http://xml.resource.org/cgi-bin/xml2rfc.cgi#RFC5922>.

The SF of the Target SSP verifies that the Identity header is valid, corresponds to the message, corresponds to the Identity-Info header, and that the domain in the From header corresponds to one of the domains in the TLS client certificate.

As noted above in Section 6.1.3.2<http://xml.resource.org/cgi-bin/xml2rfc.cgi#IPSec>, some deployments may utilize IPSec rather than TLS.



Russ Mundy