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

Simon Perreault <> Tue, 10 July 2012 20:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E25B211E80A6; Tue, 10 Jul 2012 13:31:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.485
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L9vJf1KENulu; Tue, 10 Jul 2012 13:31:36 -0700 (PDT)
Received: from (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by (Postfix) with ESMTP id 110F121F84D3; Tue, 10 Jul 2012 13:31:36 -0700 (PDT)
Received: from (unknown [IPv6:2620:0:230:c000:8e70:5aff:fec5:72e4]) by (Postfix) with ESMTPSA id 1B35A44B4E; Tue, 10 Jul 2012 16:32:04 -0400 (EDT)
Message-ID: <>
Date: Tue, 10 Jul 2012 16:32:03 -0400
From: Simon Perreault <>
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 <>
References: <> <> <>
In-Reply-To: <>
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
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: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.

DTN made easy, lean, and smart -->
NAT64/DNS64 open-source        -->
STUN/TURN server               -->