Margaret, I'm actualy not really the best person to ask about that. I have no insight into the internal workings of PCI policy making. I mostly deal with it from a standpoint compliance issues. Meaning I know what the policy is.....but I don't know much about the sausage-making process of how that policy gets crafted.
Most of my actual experience comes from getting qualified as a vendor for clients that are regulated under Gramm-Leach-Bliley which involves a security review/audit for compliance with thier corporate vendor security standards. The issues dealt with are similar but not the same. NAT has been listed as a requirement in pretty much all of those that I've dealt with.... I haven't encountered anything IPv6 specific in any of those yet.... though I'm sure it'll come along at some point. They are usualy pretty slow in adapting those policies to cover emerging technologies. Last one I dealt with had as a listed requirement to "Not use Cell Phones for business purposes, for any discusions related to business purposes or for the transmission of any sensitive data". So that should give you a good picture of what they look like. Christopher Engel -----Original Message----- From: Margaret Wasserman [mailto:[email protected]] Sent: Tuesday, November 10, 2009 4:39 PM To: Keith Moore Cc: Chris Engel; NAT66 HappyFunBall Subject: Re: [nat66] Necessity for NAT remains in IPv6 On Nov 11, 2009, at 2:20 AM, Keith Moore wrote: > Chris Engel wrote: >> >> Gentlemen, >> >> Unless I am misunderstanding how ULA works I don't see how it >> addresses the 2nd issue I raised. It provides a private address >> space, but doesn't provide any means to relate that space to your >> public address space. I don't see any abstraction there.... just the >> possibility to maintain an additional space. >> >> Example: I have a service that I publicly advertise on Network A, >> Host 1 (public address space). I provide that service on an internal >> device on Network B, Host 1 (private address space) but I want to >> move that service (either temporarily or permanently) to be provided >> on a different internal device Network B, Host 2 (private address >> space). I don't see how ULA helps with that. It allows me to have a >> private address space...but it doesn't provide any mapping of that >> space to the Public Address space... that's what NAT does. > I don't think NAT causes many problems when used in this manner - to > map specific hosts with specific, well-known, services, to specific > external addresses. The alternative would be to use a tunnel, which > has its own problems, and it's a case of choosing the lesser of two > evils. Which is better depends on specific circumstances. > > But that kind of NAT has almost nothing in common with the kind of NAT > you cite below: That kind of NAT has, of course, everything in common with NAT66. >> Finally I don't believe you would have a very successful time >> convincing a security auditor that ULA covers the PCI-DSS v1.2 >> Requirement 1.3.8, when they say use "Use network address translation >> (NAT)" that is PRECISELY what they want you to do. I've dealt alot >> with those type of audits. You are going to have a VERY tough sell >> that ULA is an acceptable "compensating control" for that. What PCI-DSS v1.2 requirement 1.3.8 actually says is: "1.3.8 Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies-for example, port address translation (PAT). " Obviously this would need to be updated to be met in IPv6 at all, as RFC 1918 is IPv4-only. The simplest change would be to use ULAs (the IPv6 replacement for RFC 1918 address space) instead. This section does not actually require port translation, although it is mentioned. So, I think you could meet this requirement for IPv6 by using ULAs for internal addressing and NAT66 to translate the RFC 1918 space to external addresses. Chris, do you know if there is any plan to update the PCI requirements to cover IPv6? Margaret _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
