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

[Sam Hartman <[e-mail]>]

>>>>> "Simon" == Simon Perreault <[e-mail]> 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?