Subject: [secdir] secdir review of draft-ietf-behave-lsn-requirements

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Jul 2012 14:16:17 -0400

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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 10 Jul 2012 15:36:47 -0400

(adding [email-masked] to the recipients list...)

Sam,

Thanks for the review, comments inline...

On 07/10/2012 02:16 PM, Sam Hartman wrote:
> 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

Thanks for the full requirements text and justification. That going to 
make my editing just so much easier!

> 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

-- 
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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Jul 2012 16:03:50 -0400

>>>>> "Simon" == Simon Perreault <[email-masked]> 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.

    >> example, I can spoof traffic from you to create an inbound hole towards

    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?

---

From: Simon Perreault <[email-masked]>
Date: Tue, 10 Jul 2012 16:32:03 -0400

> motivating the text in 13.1.

Makes sense to me.

> describing a related attack and recommending people deploy in a manner

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

---

From: Shin Miyakawa <[email-masked]>
Date: Wed, 11 Jul 2012 05:36:54 +0900 (JST)

>> motivating the text in 13.1.

+1

> benefits over either single-user NAT or no NAT at all."

I agree with Simon (also as one of the authors of this draft).

We think that CGN is not the machine to proveide security benefits
and the original intension of this draft is just to make CGN as neutral as possible...

Best wishes,

Shin Miyakawa