[Pce] Security directorate review of draft-ietf-pce-interas-pcecp-reqs-03
"Adrian Farrel" <adrian@olddog.co.uk> Mon, 01 October 2007 10:32 UTC
Return-path: <pce-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcIZH-0004xh-Hy; Mon, 01 Oct 2007 06:32:03 -0400
Received: from pce by megatron.ietf.org with local (Exim 4.43) id 1IcIZG-0004wv-K2 for pce-confirm+ok@megatron.ietf.org; Mon, 01 Oct 2007 06:32:02 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IcIZG-0004vU-7U for pce@ietf.org; Mon, 01 Oct 2007 06:32:02 -0400
Received: from heisenberg.zen.co.uk ([212.23.3.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IcIZE-000797-Dk for pce@ietf.org; Mon, 01 Oct 2007 06:32:02 -0400
Received: from [88.96.235.138] (helo=cortex.aria-networks.com) by heisenberg.zen.co.uk with esmtp (Exim 4.50) id 1IcIZD-0008AJ-90 for pce@ietf.org; Mon, 01 Oct 2007 10:31:59 +0000
Received: from your029b8cecfe ([81.140.15.32] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Oct 2007 11:31:57 +0100
Message-ID: <074701c80416$48f22700$0200a8c0@your029b8cecfe>
From: Adrian Farrel <adrian@olddog.co.uk>
To: pce@ietf.org
Date: Mon, 01 Oct 2007 11:28:58 +0100
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-OriginalArrivalTime: 01 Oct 2007 10:31:57.0902 (UTC) FILETIME=[4B4A6EE0:01C80416]
X-Originating-Heisenberg-IP: [88.96.235.138]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 1a2f5df4c6f30e0d5df43748fb095119
Cc:
Subject: [Pce] Security directorate review of draft-ietf-pce-interas-pcecp-reqs-03
X-BeenThere: pce@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
List-Id: Path Computation Element <pce.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pce>
List-Post: <mailto:pce@lists.ietf.org>
List-Help: <mailto:pce-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@lists.ietf.org?subject=subscribe>
Errors-To: pce-bounces@lists.ietf.org
Hi, We asked the Security Area Directorate to provide us with an early review of draft-ietf-pce-interas-pcep-reqs. Recently, a fair number of I-Ds from PCE and CCAMP have been falling at the security hurdle during IESG review. This seems to be particularly the case for inter-AS work, so we thought that we should try to get some feed-back before we go to WG last call, and see if we can produce a draft that better addresses the Security AD's concerns. We received comments from Sandy Murphy and Pasi Eronen as shown below. The chairs will be working with the document authors to revise the text to address the issues raised, but we would all be more than grateful for other comments and assistance. Thanks, Adrian +++++ <begin Sandy Murphy> This draft specifies the requirements for a PCE communication protocol, i.e., a protocol between PCC and PCE or inter-PCE, when the communication is taking place across AS boundaries. This AS boundary could be within one service provider or may be between service providers. The PCEs compute paths for the establishment of LSPs satisfying PCC provided constraints. This document refers to the security considerations of RFC4657, which mandates support for protections agains spoofing, snooping and DOS between the entities. The example given discusses communication that spans ASs - a PCE1 in AS1 makes a request of a PCE2 in AS2, who asks a PCE3 in AS3 . The reply from AS3 gets augmented by info from the AS2 before PCE2 replies to PCE1. This sounded like they anticipate protocols that could lead to PCE2/AS2 being able to inject bogus information supposedly from AS3 in what it passes to PCE1/AS1 (a la BGP mis-originations). This is only an example, but the intent of the protocol is to return the inter-AS path of the computed LSP, so this behavior is likely. The security requirements seem to address only hop-by-hop security - there are no requirements to ensure that the PCE providing information for which it is not "authoritative" is providing legitimate info. I.e., there's no end-end model of protecting the data. The security considerations section also note: Additionally, two aspects of operations specific to inter-AS PCEs require careful security considerations. There are two modes of determining peering PCEs across the AS boundary manual configuration and auto-discovery. In the manual mode, mechanisms for securely exchanging manually confgiured authentication key or key sets across SP boundaries MUST be defined. For example, the authentication key May be manually configured for each PCE peer and PCE registration MAY be served as a mechanism for securely exchanging authentication keys across SP boundaries. In the auto-discovery mode, inter-as PCEs can be auto-discovered only if it is configured to participate in that discovery scope. An inter-AS PCE is not necessarily able to establish PCEP sessions with the discovered PCEs in its scope(s), it MUST be able to authenticate with the peering inter-AS PCE, therefore mechanisms for securely exchanging authentication keys across SP boundaries MUST also be defined in this case. Furthermore, the auto-discovery process itself MUST also be authenticated. The first paragraph refers to manual and auto-discovery of PCEs and the problems this creates in an inter-AS situation. Other pce wg drafts/RFCs give rough orders of magnitude of 1000s of PCCs communicating with one PCE and one PCC communicating with 100s of PCEs. There's some confusion as to the distinction between PCCs and PCEs in an inter-PCE communications. So it is unclear how many inter-AS inter-PCE connections one PCE might have. But it does seem clear that manual keying could be unscalable in inter-PCE environments. I do not know what the draft means by saying that PCE registration could serve to exchange keys across SP boundaries - does it mean in the initial exchange of open messages? Auto-discovery mode needs additional consideration. RFC4674 already says that an auto-discovery protocol must ensure authenticity, integrity, and confidentiality, as well as authorization of the PCC. The present definitions of auto-discovery are extensions on ospf and isis, but that won't work here. Seems best to mandate an automated key management here - perhaps that was the intent of saying "securely exchanging authentication keys". ************************************************************ Do pay attention to RFC4107 and Sam Hartman's message to the wgchairs list reminding them/us of same. ************************************************************ Note that RFC4657 also says: Key management MUST be provided by the PCECP to provide for the authenticity and integrity of PCECP messages. This will allow protecting against PCE or PCC impersonation and also against message content falsification. I don't know that it actually meant to mandate that the PCECP had to provide key management itself as part of the protocol. But key management of some sort is clearly indicated. It just doesn't say whether that means manual or automated. =================================================================== I also took a look at the PCE communication protocol draft. draft-ietf-pce-pcep-08.txt This draft's security consideration section does not refer to the security considerations section of RFC4657 (PCEP generic requriements), which mandates that The PCC-PCE communication protocol MUST include provisions to ensure the security of the exchanges between the entities. In particular, it MUST support mechanisms to prevent spoofing (e.g., authentication), snooping (e.g., preservation of confidentiality of information through techniques such as encryption), and Denial of Service (DoS) attacks (e.g., packet filtering, rate limiting, no promiscuous listening). Once a PCC is identified and authenticated, it has the same privileges as all other PCCs. This draft does not mandate any authentication mechanism. It does RECOMMEND use of TCP-MD5. ************************************************************ Note: TCP-MD5 is technically weak. It's use in BGP required a special process exception. It is unlikely such an exception would be granted to a new use. ************************************************************ It would appear that this draft and RFC4657 are referring to hop-by-hop security only. Note: PCEP runs over TCP. It adopts the severe response model BGP uses -- it terminates a session if a mal-formed message appears or the TCP connection fails. This means it is susceptible to TCP off-path guesses at sequence numbers leading to RSTs or out-of-order data being accepted. I don't think a TLS/SSL level protection would protect the protocol. This draft differentiates behavior on receipt of some messages (e.g., NOTIFICATION) depending on whether the sender was a PCC or a PCE. I don't see that the PCC/PCE difference is communicated anywhere. The draft usually speaks only of PCC-PCE communication, not inter-PCE communication. However, RFC4674 notes that it (the rfc) makes no distinction between a PCC and a PCE acting as a PCC (because it was making a request inter-PCE). The same may be here also, so it may be possible that the role of the peer is maintained in connection state. But it is not clear that the PCE peers in the connection don't take on both PCC and PCE roles over time, so I'm not positive that helps. =================================================================== I also took a look at: rfc4674 (Requirements for PCE Discovery) This RFC says: It is also important to note that the notion of a PCC encompasses a PCE acting as PCC when requesting a path computation of another PCE (inter-PCE communication). Hence, this document does not make the distinction between PCE discovery by PCCs and PCE discovery by PCEs. The rest of the text refers to PCCs discovering PCEs, without distinguishing whether these are the "real" PCCs or PCEs acting as PCCs. This makes it difficult to determine the usual operational model for inter-AS discovery: do "real" PCCs discover the PCEs who are inter-AS capable in their own domain so that the inter-AS PCE can then discover the inter-AS PCE in a neighboring AS, or can a "real" PCC directly discover the remote ASs inter-AS PCE? The difference could make a difference in deciding on the scaling needed in a key management scheme. Note that the rfc gives order of magnitude of what the discovery design must support: - Number of PCCs discovering a given PCE: 1000 - Number of PCEs to be discovered by a given PCC: 100 But it is unclear if these are the "real" PCCs or includes PCEs that are acting as PCCs The PCE discovery mechanism MUST allow for policies to restrict the discovery scope to a set of authorized domains, to control and restrict the type and nature of the information to be disclosed, and also to filter and translate some information at domains borders. Such inter-AS PCE discovery must be carefully controlled. For security and confidentiality reasons, particularly in an inter- provider context, the discovery mechanism MUST allow the discovery scope to be limited to a set of ASs and MUST also provide control of the PCE information to be disclosed across ASs. This is achieved by applying policies (see also Section 4.4). This implies the capability to contain a PCE advertisement to a restricted set of one or more ASs, and to filter and translate any PCE parameter (PCE domains, PCE inter-domain functions, PCE capabilities, etc.) in disclosures that cross AS borders. These references to translation are probably intended to apply in cases like the example given: "translate" what is communicated internally to something else when communicated externally. But other references make it sound like some of the discovery information might come from another domain down the line: Also the PCE discovery mechanism MUST allow discovery of the inter- domain functions of a PCE, i.e., whether a PCE can be used to compute or to take part in the computation of end-to-end paths across domain borders. The inter-domain functions include nonexhaustively: inter- area, inter-AS and inter-layer path computation. Note that these functions are not mutually exclusive. Note that the inter-domain functions are not necessarily inferred from the set of domains where a PCE has visibility. For instance, a PCE may have visibility limited to a single domain, but may be able to take part in the computation of inter-domain paths by collaborating with PCEs in other domains. In such a case, "translating" information starts to sound more troubling - it could be "translating" information which came from some other domain. The hop-by-hop integrity protections would be useless against changes made by the peer PCE. +++++ <end Sandy Murphy> +++++ <begin Pasi Eronen> I was assigned to do an early Security Directorate review of draft-ietf-pce-interas-pcecp-reqs-03 ("Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)"). This is certainly one of the most difficult SecDir review assignments I've gotten so far. The document itself is only 13 pages, but it required quite a lot of background reading; and the security issues seem to span a rather large set of documents, none of which can be fully considered alone. So, a disclaimer is in order: I'm not very familiar with the topic area (PCE, MPLS), and this review is in no sense thorough or exhaustive. In general, the documents seem rather well written, and consider security broadly (not just cryptographic mechanisms for protecting messages, but also e.g. revealing sensitive information to authenticated communication nodes, etc.). However, I identified at least the following topics that IMHO require further clarification: 1) Interaction between PCE discovery and PCEP communication security It looks like there's a rather large disconnect between the PCE discovery drafts (which assumes that PCCs can dynamically and automatically discover PCEs) and the actual PCE protocol document (which uses communication security mechanisms that essentially require manual configuration of each PCC-PCE relationship). Or in other words: if you use TCP-MD5, and anyway have to manually configure the shared secrets and PCC/PCE IP addresses at each PCE/PCC, the benefits of having a discovery mechanism are quite limited (the capability part might still be useful, though). Using something else than TCP-MD5, such as IPsec, does not fundamentally change the situation. If you use shared secrets (that are really pairwise shared secrets, and not shared by all devices in a domain), they need pairwise configuration. Some kind of PKI might reduce the configuration work from O(N^2) to O(N), but that has challenges, too. 2) PCE discovery/communication security, inter-AS case The previous issue is likely to be more complex in the inter-AS case. The interas-pcep-reqs draft basically states that "mechanisms for securely exchanging manually configured authentication key ... across SP boundaries MUST be defined". However, it's not clear whether this mechanism is intended to be (or even can be) purely a network protocol, or whether it's more a "ceremony" or "procedure" involving off-line human interaction. Or in other words: is the intent to define, for example, a key management protocol for TCP-MD5 (possibly based on existing security relationships in e.g. BGP or IGP)? Or something else completely? 3) Use of TCP-MD5 The PCEP draft specifies TCP-MD5 as the recommended security mechanism. I am not, at this time, suggesting that it would be better to use X instead -- but it's probable that some else will, and that any new protocol attempting to use TCP-MD5 will raise some questions. At least a good explanation is likely to be required. 4) IPsec details The PCEP draft basically says that IPsec MAY be used. This is nowhere near enough; see e.g. draft-bellovin-useipsec-06 for a starting point. 5) PCE policies vs. message authentication One topic that has received relatively little discussion is the relationship of policies based on the identity or other attributes (such as AS) of a PCC, and the cryptographic mechanisms for authenticating messages. The challenge is that the policy at the PCE might be expressed in terms of identifiers/properties of PCC that are not readily supplied (or authenticated) by the PCC-PCE message authentication mechanism. For example, if a PCE configures TCP-MD5 key to protect all messages coming from 192.0.2.1 with key "secret", it would be straightforward to have a PCE policy "for requests coming from PCC 192.0.2.1, avoid paths with (some criteria)". However, a policy "for requests coming from Example Operator Inc., avoid paths with..." (or "...coming from AS 1234...") would require additional information (possibly via manual configuration) to determine how the request should be processed (e.g., mapping authenticated PCC identity to the identifier/property used in the policy in a secure fashion). Such a manual configuration is certainly doable -- especially in case where all the other information (such as shared secrets) is manually configured as well -- but is slightly more problematic if PKI-based authentication is envisioned. If the certificate doesn't contain the identifiers/properties you need, per-PCC manual configuration might still be needed. This may also limit the types of policies you can easily use. 6) Policies in different PCEs and verifying correct operation One important manageability consideration in RFC 4655 is verifying correct operation, in particular assessing the validity of the computed paths. This is likely to be especially challenging in inter-AS case, as any single operator does not necessarily have management access to all the PCEs involved in a computation. This is further complicated by inter-AS rewriting/reinterpretation of parameters, constraints, and policies. Such rewriting/reinterpretation could also include malicious intent, and thus may be a security issue. +++++ <end Pasi Eronen> _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce
- [Pce] Security directorate review of draft-ietf-p… Adrian Farrel