On 4/18/14 10:16 PM, "Matt Palmer" <mpalmer@hezmatt.org> wrote:
On Fri, Apr 18, 2014 at 10:04:35PM -0400, Jeff Kell wrote:
As to address the other argument in this threat on NAT / private addressing, PCI requirement 1.3.8 pretty much requires RFC1918 addressing of the computers in scope... has anyone hinted at PCI for IPv6?
1.3.8 lists use of RFC1918 address space as one of four possible implementations, immediately after the phrase "may include, but are not limited to". I don't interpret that as "pretty much requires RFC1918".
It's not clear whether those are alternatives or should all be employed. An auditor will tend to recommend all of them.
Now, if you'd like to claim that 1.3.8 is completely useless, I won't argue with you -- it's security-by-obscurity of the worst possible form. But don't blame PCI compliance for any inability to deploy IPv6, because it just ain't true.
"Methods used to meet the intent of this requirement may vary depending on the specific networking technology being used. For example, the controls used to meet this requirement may be different for IPv4 networks than for IPv6 networks." https://www.pcisecuritystandards.org/documents/PCI_DSS_v3.pdf Based on my experience with compliance auditors, they won't understand many of the words in this sentence, and will assume NAT and RFC1918. They can often (but not always) be taught, but you have to take the time to explain how IPv6 works, and how you prevent a reconnaissance attack. Many enterprise network administrators are not up to this task, unfortunately. ULA + NPT66 should be pretty easy to explain, both technically, and as a method of demonstrating compliance. However, preventing outbound route leaks of more-specifics, and blocking inbound recon attacks/probes *should* be equally compliant. Lee