(adding pcp(_at_)ietf(_dot_)org 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