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