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

Sam Hartman <hartmans-ietf@mit.edu> Tue, 10 July 2012 20:03 UTC

Return-Path: <hartmans@painless-security.com>
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 B9FC411E80BB; Tue, 10 Jul 2012 13:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.301
X-Spam-Level:
X-Spam-Status: No, score=-103.301 tagged_above=-999 required=5 tests=[AWL=-1.036, 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 uC6L2XxaUAqr; Tue, 10 Jul 2012 13:03:31 -0700 (PDT)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA3A21F86B4; Tue, 10 Jul 2012 13:03:31 -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 F06E12043E; Tue, 10 Jul 2012 16:04:27 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A323441F0; Tue, 10 Jul 2012 16:03:50 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Simon Perreault <simon.perreault@viagenie.ca>
References: <tslobnna3da.fsf@mit.edu> <4FFC844F.3010207@viagenie.ca>
Date: Tue, 10 Jul 2012 16:03:50 -0400
In-Reply-To: <4FFC844F.3010207@viagenie.ca> (Simon Perreault's message of "Tue, 10 Jul 2012 15:36:47 -0400")
Message-ID: <tsl1ukj9ye1.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="us-ascii"
Cc: secdir@ietf.org, pcp@ietf.org, Sam Hartman <hartmans-ietf@mit.edu>, 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:03:32 -0000

>>>>> "Simon" == Simon Perreault <simon.perreault@viagenie.ca> writes:




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

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

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