Re: [secdir] [pcp] secdir review of draft-ietf-behave-lsn-requirements

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

Return-Path: <simon.perreault@viagenie.ca>
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 E25B211E80A6; Tue, 10 Jul 2012 13:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.485
X-Spam-Level:
X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.115, 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 L9vJf1KENulu; Tue, 10 Jul 2012 13:31:36 -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 110F121F84D3; Tue, 10 Jul 2012 13:31:36 -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 1B35A44B4E; Tue, 10 Jul 2012 16:32:04 -0400 (EDT)
Message-ID: <4FFC9143.40407@viagenie.ca>
Date: Tue, 10 Jul 2012 16:32:03 -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>
References: <tslobnna3da.fsf@mit.edu> <4FFC844F.3010207@viagenie.ca> <tsl1ukj9ye1.fsf@mit.edu>
In-Reply-To: <tsl1ukj9ye1.fsf@mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 10 Jul 2012 13:34:10 -0700
Cc: secdir@ietf.org, pcp@ietf.org, draft-ietf-behave-lsn-requirements@tools.ietf.org, ietf@ietf.org
Subject: Re: [secdir] [pcp] 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 20:31:37 -0000

On 07/10/2012 04:03 PM, Sam Hartman wrote:
>      >> and MUST NOT support the third-party option.
>
>      Simon> I think pcp-base-26 added restrictions to THIRD_PARTY so that it could
>      Simon> be used in CGN scenarios. If that is right, wouldn't it then make
>      Simon> sense to allow THIRD_PARTY on CGNs?
>
> I don't think you can describe an subscriber-facing network of an ISP as
> "fully trusted."
> The text added to 13.1 might permit third_party to be used by an
> administrative web service within an ISP  but certainly not by customers
> of that ISP.
> I'd be OK with "MUST NOT allow the third_party option for traffic
> recieved from customer-facing interfaces."
> or "MUST NOT allow the third_party option in requests received on the
> internal network."
> Then that still permits the case of third_party for administration
> motivating the text in 13.1.

Makes sense to me.

>      >> 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.
>
>      Simon> Is this a new attack vector introduced by CGN? Without NAT, there's no
>      Simon> need for a "hole", anyone can send traffic to any of a subscriber's
>      Simon> ports...
>
> I find it difficult to answer that question. I'd say that it is likely
> an unexpected assumption for someone behind a NAT.  It is a
> vulnerability of CGNs over other NATs, but perhaps not a vulnerability
> of CGNs over no NAT or firewall at all.
> Why do we care whether it's new? Is it actually bad if we end up
> describing a related attack and recommending people deploy in a manner
> that avoids it?

The DoS part is new. If an evil subscriber creates mappings in your 
stead, you may be DoSed. This attack vector does not exist with neither 
single-user NAT nor no NAT at all. That's why we mention it in the 
security considerations.

I don't think it is useful to recommend ingress filtering to prevent 
unwanted traffic because it would rely on an unrealistic assumption of a 
new security benefit that a CGN would provide. CGN does not prevent a 
subscriber from receiving traffic from anyone. That's true even with 
ingress filtering.

How about adding a sentence like...

"CGN as described in this document does not provide any security 
benefits over either single-user NAT or no NAT at all."

I don't think we have any power to change a subscriber's unreasonable 
assumptions, but we can at least honestly say to operators that they're 
not buying any security with CGN.

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