[secdir] secdir review of draft-ietf-behave-lsn-requirements
Sam Hartman <hartmans-ietf@mit.edu> Tue, 10 July 2012 18:16 UTC
Return-Path: <hartmans@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0C521F8710; Tue, 10 Jul 2012 11:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.346
X-Spam-Level:
X-Spam-Status: No, score=-103.346 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fxd2cRpF5pUz; Tue, 10 Jul 2012 11:16:00 -0700 (PDT)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 22C6821F870B; Tue, 10 Jul 2012 11:15:59 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F1726202D8; Tue, 10 Jul 2012 14:16:53 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B9E1D41F0; Tue, 10 Jul 2012 14:16:17 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: secdir@ietf.org, ietf@ietf.org
Date: Tue, 10 Jul 2012 14:16:17 -0400
Message-ID: <tslobnna3da.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Cc: draft-ietf-behave-lsn-requirements@tools.ietf.org
Subject: [secdir] secdir review of draft-ietf-behave-lsn-requirements
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 18:16:01 -0000
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. This is a document describing requirements for CGNs in order to maximize interoperability. It's similar to other documents behave has already published. One area where requirements are considered is security. For the most part, this document looks very good. Unfortunately, I do have two significant concerns. Requirement 9 requires a Port Control Protocol (PCP) server. I think we need to say somewhat more about that in order for PCP to be secure on a CGN. In this discussion I urge people to read section 17.1 (the simple thread model) of draft-ietf-pcp-base. We want to be using the simple threat model because there's no clear credential that CGN operators are guaranteed to share with their customers. If we ask people to set up a credential and configure an authentication mechanism to take advantage of the CGN's PCP server, people will either ignore our recommendations or CGN PCP will be useless. The cardinal rule of the simple threat model is do no harm: make sure that PCP cannot be used in a manner that makes security worse than implicit NAT mappings. The CGN situation is a bit more complex than the typical simple threat model. I spent this morning going over the CGN case with Margaret Wasserman and based on that discussion, I believe the following additional requirements are sufficient to use the simple threat model for CGNs. The PCP server MUST NOT permit the lifetime of a mapping to be reduced beyond its current life, MUST NOT permit a NAT mapping to be created with a lifetime less than the lifetime used for implicit mappings, MUST not permit the delete opcode to be used, and MUST NOT support the third-party option. The map opcode MAY be permitted if the recommendation of endpoint independent filtering behavior described in REQ-7 is adopted; the map opcode MUST NOT be permitted in other circumstances. These constraints MAY be relaxed if a security mechanism consistent with PCP's Advanced Threat Model (see Section 17.2 of [I-D.ietf-pcp-base]) is used; this is expected to be rare for CGN deployments. Mappings created by PCP MUST follow the same deallocation behavion (REQ-8) as implicitly mapped traffic. justification: Most of the concern has to do with one customer device interacting negatively with the security of another; this is of particular concern when the devices belong to different customers, but devices belonging to the same customer are in scope for the PCP security analysis as well. Reducing a mapping lifetime or deleting a mapping create DOS opportunities and can create an opportunity for one device to intercept another device's traffic. If a device spoofs creation of a mapping with less than the default lifetime, then that can create DOS or packet capture opportunities. The third-party option creates significant spoofing opportunities. The behavior of REQ-8 is critical to avoiding packet capture attacks. My second concern is with section 8. This section says that spoofing is a concern of DOS, notes that ingress filtering is a defense and makes no recommendation. I believe spoofing is a significantly greater concern than DOS. As an example, I can spoof traffic from you to create an inbound hole towards one of your ports. This is particularly valuable if the filtering behavior is endpoint independent as recommended in REQ-7. Spoofing is particularly dangerous with PCP if the constraints I listed above are not followed. The analysis of the impact of spoofing is a bit tricky, because it depends on how spoofing is accomplished and on whether an attacker can observe traffic destined for other customers as well. So, I think the warning about spoofing needs to be increased. I also think we need to make a specific recommendation that people deploying CGNs deploy sufficient ingress filtering to avoid spoofing. I understand this specification is mostly about building CGNs not about deploying them. However this issue seems quite important to the security of the network. Thanks, --Sam
- [secdir] secdir review of draft-ietf-behave-lsn-r… Sam Hartman
- Re: [secdir] secdir review of draft-ietf-behave-l… Simon Perreault
- Re: [secdir] [pcp] secdir review of draft-ietf-be… Sam Hartman
- Re: [secdir] [pcp] secdir review of draft-ietf-be… Simon Perreault
- Re: [secdir] [pcp] secdir review of draft-ietf-be… Shin Miyakawa