Re: secdir review of draft-ietf-behave-lsn-requirements

Simon Perreault <simon.perreault@viagenie.ca> Tue, 10 July 2012 19:36 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723EE21F86C5; Tue, 10 Jul 2012 12:36:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.456
X-Spam-Level:
X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, NO_RELAYS=-0.001]
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 gPB+winjd+gD; Tue, 10 Jul 2012 12:36:22 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 6341121F86C4; Tue, 10 Jul 2012 12:36:22 -0700 (PDT)
Received: from porto.nomis80.org (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 1D294414B1; Tue, 10 Jul 2012 15:36:48 -0400 (EDT)
Message-ID: <4FFC844F.3010207@viagenie.ca>
Date: Tue, 10 Jul 2012 15:36:47 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: secdir review of draft-ietf-behave-lsn-requirements
References: <tslobnna3da.fsf@mit.edu>
In-Reply-To: <tslobnna3da.fsf@mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: pcp@ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org, ietf@ietf.org, secdir@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2012 19:36:23 -0000

(adding pcp@ietf.org to the recipients list...)

Sam,

Thanks for the review, comments inline...

On 07/10/2012 02:16 PM, Sam Hartman wrote:
> 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,

Unless I'm mistaken, there is no delete opcode in PCP. You just send a 
MAP request with lifetime=0. So I would propose saying:

MUST NOT permit the lifetime of a mapping to be reduced beyond its 
current life or be set to zero (deleted)

> and MUST NOT support the third-party option.

I think pcp-base-26 added restrictions to THIRD_PARTY so that it could 
be used in CGN scenarios. If that is right, wouldn't it then make sense 
to allow THIRD_PARTY on CGNs?

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

Thanks for the full requirements text and justification. That going to 
make my editing just so much easier!

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

Is this a new attack vector introduced by CGN? Without NAT, there's no 
need for a "hole", anyone can send traffic to any of a subscriber's ports...

Thanks,
Simon

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

-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca