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

Sam Hartman <> Tue, 10 July 2012 20:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9FC411E80BB; Tue, 10 Jul 2012 13:03:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.301
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uC6L2XxaUAqr; Tue, 10 Jul 2012 13:03:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2CA3A21F86B4; Tue, 10 Jul 2012 13:03:31 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by (Postfix) with ESMTPS id F06E12043E; Tue, 10 Jul 2012 16:04:27 -0400 (EDT)
Received: by (Postfix, from userid 8042) id A323441F0; Tue, 10 Jul 2012 16:03:50 -0400 (EDT)
From: Sam Hartman <>
To: Simon Perreault <>
References: <> <>
Date: Tue, 10 Jul 2012 16:03:50 -0400
In-Reply-To: <> (Simon Perreault's message of "Tue, 10 Jul 2012 15:36:47 -0400")
Message-ID: <>
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:,, Sam Hartman <>,,
Subject: Re: [secdir] [pcp] secdir review of draft-ietf-behave-lsn-requirements
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jul 2012 20:03:32 -0000

>>>>> "Simon" == Simon Perreault <> writes:

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

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