(adding pcp@xxxxxxxx to the recipients list...) Sam, Thanks for the review, comments inline... On 07/10/2012 02:16 PM, Sam Hartman wrote:
Requirement 9 requires a Port Control Protocol (PCP) server. I think we need to say somewhat more about that in order for PCP to be secure on a CGN. In this discussion I urge people to read section 17.1 (the simple thread model) of draft-ietf-pcp-base. We want to be using the simple threat model because there's no clear credential that CGN operators are guaranteed to share with their customers. If we ask people to set up a credential and configure an authentication mechanism to take advantage of the CGN's PCP server, people will either ignore our recommendations or CGN PCP will be useless. The cardinal rule of the simple threat model is do no harm: make sure that PCP cannot be used in a manner that makes security worse than implicit NAT mappings. The CGN situation is a bit more complex than the typical simple threat model. I spent this morning going over the CGN case with Margaret Wasserman and based on that discussion, I believe the following additional requirements are sufficient to use the simple threat model for CGNs. The PCP server MUST NOT permit the lifetime of a mapping to be reduced beyond its current life, MUST NOT permit a NAT mapping to be created with a lifetime less than the lifetime used for implicit mappings, MUST not permit the delete opcode to be used,
Unless I'm mistaken, there is no delete opcode in PCP. You just send a MAP request with lifetime=0. So I would propose saying:
MUST NOT permit the lifetime of a mapping to be reduced beyond its current life or be set to zero (deleted)
and MUST NOT support the third-party option.
I think pcp-base-26 added restrictions to THIRD_PARTY so that it could be used in CGN scenarios. If that is right, wouldn't it then make sense to allow THIRD_PARTY on CGNs?
The map opcode MAY be permitted if the recommendation of endpoint independent filtering behavior described in REQ-7 is adopted; the map opcode MUST NOT be permitted in other circumstances. These constraints MAY be relaxed if a security mechanism consistent with PCP's Advanced Threat Model (see Section 17.2 of [I-D.ietf-pcp-base]) is used; this is expected to be rare for CGN deployments. Mappings created by PCP MUST follow the same deallocation behavion (REQ-8) as implicitly mapped traffic. justification: Most of the concern has to do with one customer device interacting negatively with the security of another; this is of particular concern when the devices belong to different customers, but devices belonging to the same customer are in scope for the PCP security analysis as well. Reducing a mapping lifetime or deleting a mapping create DOS opportunities and can create an opportunity for one device to intercept another device's traffic. If a device spoofs creation of a mapping with less than the default lifetime, then that can create DOS or packet capture opportunities. The third-party option creates significant spoofing opportunities. The behavior of REQ-8 is critical to avoiding packet capture attacks.
Thanks for the full requirements text and justification. That going to make my editing just so much easier!
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.
Is this a new attack vector introduced by CGN? Without NAT, there's no need for a "hole", anyone can send traffic to any of a subscriber's ports...
Thanks, Simon
This is particularly valuable if the filtering behavior is endpoint independent as recommended in REQ-7. Spoofing is particularly dangerous with PCP if the constraints I listed above are not followed. The analysis of the impact of spoofing is a bit tricky, because it depends on how spoofing is accomplished and on whether an attacker can observe traffic destined for other customers as well. So, I think the warning about spoofing needs to be increased. I also think we need to make a specific recommendation that people deploying CGNs deploy sufficient ingress filtering to avoid spoofing. I understand this specification is mostly about building CGNs not about deploying them. However this issue seems quite important to the security of the network.
-- 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