>>>>> "Simon" == Simon Perreault <simon.perreault@xxxxxxxxxxx> 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?