I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
This is a document describing requirements for CGNs in order to maximize
interoperability. It's similar to other documents behave has already
published. One area where requirements are considered is security.
For the most part, this document looks very good. Unfortunately, I do
have two significant concerns.
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, and MUST NOT support the
third-party option. 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.
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. 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.
Thanks,
--Sam