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

[Simon Perreault <[e-mail]>]

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