Re: [v6ops] Vicious circle [ULA precedence [Thoughts about wider operational input]]

[Nick Buraglio <[e-mail]>]

I think the context here is pretty spot on, actually. It reflects reality,
even if that reality isn't exactly what was the ideal intention.
That is the thing about enterprises - especially financial and medical
systems - they don't live by any calendar but their own, and actively avoid
timing that costs money that is difficult to justify, and that is where we
circle back to risk and cost.
I'm not saying that working with the compliance folks is not a good goal,
just that "timely" likely isn't the cards, meanwhile v6 will continue to
get poor enterprise adoption.   That said, we have strayed pretty far off
the path of ULA being dereferenced to the point of non-use in dual-stacked
networks. How do we address that specific problem without fixating on if
NAT is "good" or "bad"?

nb
ᐧ

---
Nick Buraglio
Planning and Architecture
Energy Sciences Network
[phone]


On Wed, Apr 27, 2022 at 2:18 PM JORDI PALET MARTINEZ <jordi.palet=
[e-mail]> wrote:

> All this looks very nice, but clearly outdated and taken out of context.
> They are looking for 20+ years old technology.
>
>
>
> Why the IETF will want to adapt standards to outdated technologies,
> instead of working with PCI, looking for stablishing a liaison, training
> them and helping to do a **good job**?
>
>
>
> Regards,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 27/4/22, 20:03, "v6ops en nombre de Kevin Myers" <
> [e-mail] en nombre de [e-mail]>
> escribió:
>
>
>
> Here is some context on the question “what requirements force the use of
> NAT?” in PCI-DSS 4.0.
>
> As others have noted, it’s up to the auditor to interpret this (because
> they bear the financial and legal liability as well as the org) to
> determine which aspects of PCI drive protocols like NAT – it’s not just one
> thing. 1.3.7 is a clear call out for the use of NAT and is the **only**
> reference to IPv6 in over 300 pages of the PCI-DSS standard which was just
> updated in March 2022 and probably won’t be again for another 2 to 4 years.
> The single mention of IPv6 is also not cleanly reconciled against the other
> requirements nor is it on the radar of most any of the auditors and
> existing processes.
>
> To give a more recent example from a large financial enterprise we
> currently do the global DC design for - here are some of the PCI sections
> we had to reference that required this org to use NAT and RFC1918 to pass
> their audit.
>
> PCI 1.4.1 is one of the more common call outs for NAT + RFC1918 as the
> auditors interpret them.
>
>
>
> It advocates for the use of a DMZ that will control access between
> untrusted networks (generally interpreted as the Internet as well as
> Non-PCI internal networks) and is often combined with 1.3.7’s requirement
> for address obfuscation. From a network engineering standpoint as the
> auditors see it, the enterprise DC must have:
>
> 1. An NSC – Network Security Device to form the DMZ and provide NAT (ref
> 1.4)
> 2. NAT as part of the 1.4.1 control for trusted to untrusted (and to
> satisfy address obfuscation - ref 1.3.7)
> 3. Rulesets that prohibit untrusted to trusted communication except for
> authorized systems. (1.3.1 and 1.3.2)
>
> Again to align this to real world ops – this is exactly what we had to
> implement for the fintech org I’m using as an a example and satisfy the
> auditor’s requirements.
>
> Clearly, we can technically achieve all of these in an IPv6 network
> without the use of RFC1918 or NAT – that’s not the challenge. The problem
> is that the auditors (again – these are accountants and biz people) have a
> framework that’s been developed around RFC1918 and NAT to sign off on a PCI
> compliant network for these sections.
>
> But it gets a bit harder, here's where things get murky for IPv6 without
> NAT in 1.4.4
>
>
> 1.4.4 states “System components that store cardholder data are NOT
> directly accessible from untrusted networks.” Most auditors also interpret
> 1.4.4 as a requirement for NAT in the DMZ and puts IPv6 “end to end”
> connectivity in direct conflict with audit compliance. Not only does it
> imply NAT, it also is interpreted by the auditors to mean non-publicly
> routable space in the trusted zone. The technical definition of “direct
> accessibility” as we would view it in network engineering is irrelevant to
> the average auditor because they have a list of acceptable ways to solve
> this and IPv6 end to end isn’t on that list – however RFC1918 and NAT very
> much are.
>
> To sum up, that’s three different sections that would require an exception
> and compensating control from the auditor to implement IPv6. Not only do
> exceptions risk audit non-compliance, exceptions also cost exorbitant
> amounts of money for the org to justify with the auditor. As David Farmer
> correctly pointed out, exceptions are the kiss of death in audit land – no
> enterprise will push for multiple exceptions when a viable alternative
> (from the PoV of the enterprise and auditor) is available – in this case
> it’s RFC1918 and NAT. As for the question around RFC4864 and updating it, I
> need to dig into that beyond the abstract and give it some thought as it
> would apply to the Enterprise I’m referencing in this example.
>
> This is a bit of a glimpse into why companies that are bound by PCI
> compliance aren’t rushing to go put IPv6 into their networks without
> transition technologies like NAT.
>
> *From:* v6ops <[e-mail]> *On Behalf Of *Nick Buraglio
> *Sent:* Monday, April 25, 2022 7:50 PM
> *To:* Ted Lemon <[e-mail]>
> *Cc:* 6man list <[e-mail]>; David Farmer <farmer=
> [e-mail]>; Erik Auerswald <[e-mail]>;
> Ted Lemon <[e-mail]>; v6ops list <[e-mail]>
> *Subject:* Re: [v6ops] Vicious circle [ULA precedence [Thoughts about
> wider operational input]]
>
>
>
> With PCI it seems to be all about the auditor. Kevin definitely knows this
> experience inside out, he personally and his company have been neck deep in
> this stuff for a long time.
>
> nb
>
>
>
> On Mon, Apr 25, 2022 at 19:47 Ted Lemon <[e-mail]> wrote:
>
> That requirement requires that servers' (doesn't say what sort of servers,
> I assume that's specified elsewhere) IP addresses can't be visible to
> whatever is using the server. NAT is about the least safe way to accomplish
> this goal. They explicitly mention several other ways, and do not mention
> NAT at all. Sounds fishy.
>
>
>
> Note that these same people as far as I know /still/ allow TLS 1.1. Which
> suggests to me that exceptions are easy if they are exceptions the examiner
> is accustomed to, irrespective of whether those exceptions are more or less
> risky than other exceptions the examiner is not accustomed to.
>
>
>
> On Mon, Apr 25, 2022 at 8:38 PM David Farmer <farmer=
> [e-mail]> wrote:
>
> I’ve asked that too and have never received an answer, I always get
> pointed requirement 1.3.7, that is it.
>
>
>
> Sorry, I can’t be more helpful.
>
>
>
> On Mon, Apr 25, 2022 at 18:58 Brian Carpenter <[e-mail]>
> wrote:
>
> No, I explicitly don't want to look at audit rules. I want someone who
> understands them to explain what the functional requirements are. NAT is
> not a functional requirement.
>
> Regards,
>     Brian Carpenter
>     (via tiny screen & keyboard)
>
>
>
> On Tue, 26 Apr 2022, 11:06 David Farmer, <[e-mail]> wrote:
>
> You want to look at PCI DSS 3.2 requirement 1.3.7.
>
>
>
> Compensating controls is an option, but auditors have to sign off on them,
> and the whole process is about minimizing exceptions and getting a clean
> audit. IT isn't in charge of this, finance people are, it's not technical,
> it's all about the money, and numbers with 7 or 8 significant digits or
> more.
>
>
>
> I've been on that the merry-go-round several times, I believe in IPv6 E2E,
> but if anyone asks me just do NPTv6 or NAT66, whatever the auditor wants
> you to do.
>
>
>
> Have fun on the merry-go-round, I'll pass.
>
>
>
> Thanks
>
>
>
> On Mon, Apr 25, 2022 at 5:32 PM Brian E Carpenter <
> [e-mail]> wrote:
>
> Kevin,
>
> > Auditing frameworks and auditors are just not ready for IPv6 and without
> migration strategies like NAT, they'll have no reason to be because IPv4
> will continue to dominate.
>
> You're describing a vicious circle, and the question is how can we break
> it?
>
> Advocating NPTv6 might achieve that, but many of us dislike that strategy.
>
> Can you explain what are the technical requirements in PCI-DSS land that
> have been interpreted as requiring NAT44? Is it time for RFC4864bis,
> because this is exactly what we were aiming at with that RFC?
>
> Regards
>     Brian Carpenter
>
> On 25-Apr-22 17:34, Kevin Myers wrote:
> > This misses the problem entirely though.
> >
> > It's not a choice to reconsider, these are regulatory requirements. The
> fact that a handful of enterprises have deployed IPv6 doesn't move the
> needle on compliance for the vast majority of them.
> >
> > No retail enterprise is going to choose IPv6 without NAT internally if
> it means not being permitted to use credit cards because of a failed
> PCI-DSS audit.
> >
> > Auditing frameworks and auditors are just not ready for IPv6 and without
> migration strategies like NAT, they'll have no reason to be because IPv4
> will continue to dominate.
> >
> >
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> > *From:* Lorenzo Colitti <[e-mail]>
> > *Sent:* Sunday, April 24, 2022, 11:27 PM
> > *To:* Kevin Myers <[e-mail]>
> > *Cc:* Brian E Carpenter <[e-mail]>; Erik Auerswald <
> [e-mail]>; Ted Lemon <[e-mail]>; v6ops list <
> [e-mail]>; 6man list <[e-mail]>
> > *Subject:* Re: [v6ops] ULA precedence [Thoughts about wider operational
> input]
> >
> > There are several fortune 500 companies that have publicly stated that
> they have deployed IPv6 with global addressing, so that's definitely
> possible.
> >
> > As for "is it better to deploy IPv6 with NAT66 or not to deploy at all",
> I would guess it depends who you ask. My personal answer would be no. It's
> possible that when faced with app and OS incompatibilities, those
> enterprises might reconsider. Or they might pick the same technical
> solutions as the enterprises that have already deployed with global
> addresses.
> >
> > On Mon, Apr 25, 2022 at 12:42 PM Kevin Myers <
> [e-mail] <mailto:[e-mail]>> wrote:
> >
> >     IPv6 NAT is already being deployed in large enterprises for the few
> that want to tackle IPv6. Vendor implementations exist, so that ship has
> sailed regardless of where the IETF lands.
> >
> >     Most of the Fortune 500 fall under regulatory compliance of one body
> or another (PCI-DSS, FIPS, HIPAA, etc) and none of them are setup well for
> an IPv6 no-NAT world. Most of the discussion I see around enterprise
> adoption on the IETF lists misses this point. It matters very little
> whether NAT is a "good" or "bad" practice when it comes to selecting an
> operational model. Enterprises choose operational models that will pass
> audits
> and the overwhelming majority rely heavily on NAT.  We can make the
> argument that compliance bodies and auditors should update their guidance
> and standards and they absolutely should, but it will probably take close
> to a decade to change the regulatory compliance auditing landscape to the
> point that IPv6 without NAT is commonplace.
> >
> >     If auditors won't sign off on end to end GUA addressing, then NAT is
> going to remain.
> >
> >     Enterprises are more than willing to punt IPv6 for another decade
> and will likely have no issues in doing so given how little IPv4 space most
> of them need compared to service providers. Even when IPv6 becomes the
> predominant transport type for an Internet handoff everywhere, it will
> still just live in the underlay while IPv4 remains the predominant choice
> in the overlay, in apps,  and internally in the DC for enterprises.
> >
> >     At what point does it become more important to have IPv6
> implemented, than to have it "perfectly" implemented?
> >
> >     Kevin Myers
> >     Sr. Network Architect
> >     IP ArchiTechs
> >
> >     -----Original Message-----
> >     From: v6ops <[e-mail] <mailto:[e-mail]>>
> On Behalf Of Brian E Carpenter
> >     Sent: Sunday, April 24, 2022 9:48 PM
> >     To: Lorenzo Colitti <lorenzo=[e-mail] <mailto:
> [e-mail]>>; Erik Auerswald <[e-mail]
> <mailto:[e-mail]>>; Ted Lemon <[e-mail] <mailto:
> [e-mail]>>
> >     Cc: v6ops list <[e-mail] <mailto:[e-mail]>>; 6man list <
> [e-mail] <mailto:[e-mail]>>
> >     Subject: Re: [v6ops] ULA precedence [Thoughts about wider
> operational input]
> >
> >     On 25-Apr-22 12:16, Lorenzo Colitti wrote:
> >      > On Mon, Apr 25, 2022 at 2:28 AM Erik Auerswald <
> [e-mail] <mailto:[e-mail]> <mailto:
> [e-mail] <mailto:[e-mail]>>> wrote:
> >      >
> >      >       "Since ULAs are defined to have a /48 site prefix, an
> implementation
> >      >        might choose to add such a row automatically on a machine
> with
> >      >        a ULA."
> >      >
> >      >     The result is that only the local ULA prefix,
> i.e., exactly the
> >      >     local IPv6 addresses, are preferred over IPv4
> (and IPv6 GUA).
> >      >     This should be exactly what is needed to use ULA addresses
> inside
> >      >     an organization, or for a lab.
> >      >     [...]
> >      >     Implementing the non-normative suggestion from Section 10.6
> of RFC
> >      >     6724 would in all likelihood result in making
> ULA usable for local
> >      >     tests and even first steps in deploying IPv6.  ULA addresses
> would
> >      >     only be used locally.  Existing IPv4 based Internet access
> would not
> >      >     be impaired by adding IPv6 ULA.
> >      >
> >      >
> >      > That does seem like it might make ULA more useful, yes.
> >      >
> >      > Additionally, maybe we could clarify that the longest-prefix
> match rule
> >     does not apply to ULAs outside the same /48? I think that would fix
> the issue observed by +Ted Lemon <mailto:[e-mail] <mailto:
> [e-mail]>> in home networks:
> https://datatracker.ietf.org/meeting/113/materials/slides-113-6man-source-address-selection-for-foreign-ulas-00
> <
> https://datatracker.ietf.org/meeting/113/materials/slides-113-6man-source-address-selection-for-foreign-ulas-00>
> <
> https://datatracker.ietf.org/meeting/113/materials/slides-113-6man-source-address-selection-for-foreign-ulas-00
> <
> https://datatracker.ietf.org/meeting/113/materials/slides-113-6man-source-address-selection-for-foreign-ulas-00>>
> .
> >
> >     When two networks each with its own ULA prefix are intentionally
> merged, longest match would be the right thing, wouldn't it? (Assuming that
> the split DNSs are also merged, and of course internal routing.) In that
> case there is no "foreign" ULA prefix.
> >
> >      >     In order to keep IPv6 deployment similar to IPv4, IPv6 NAT
> could be
> >      >     considered.  To make this work as intended, the address
> selection
> >      >     policy table could be adjusted to contain the
> local ULA prefix
> >      >     with precedence greater or equal to GUA and the same label as
> GUA.
> >      >
> >      >
> >      > This seems like it would encourage the use of IPv6 NAT. I think
> there is reasonably strong consensus within the IETF that that is not the
> right way to go, because it pushes problems on to application developers.
> This adds costs for NAT traversal software development and maintenance,
> and requires devices to implement NAT keepalives, increasing battery usage.
> >
> >     That may be the IETF's consensus, but there is a very large fraction
> of the enterprise network operations community that strongly disagrees,
> and in fact regards this as a red line issue. It isn't even clear that
> they'd accept NPTv6 as an alternative to NAPT66. If this is indeed the only
> way to get IPv6 inside enterprises, what is the right thing for the IETF
> to do?
> >
> >             Brian
> >
> >     _______________________________________________
> >     v6ops mailing list
> >     [e-mail] <mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/v6ops <
> https://www.ietf.org/mailman/listinfo/v6ops>
> >
> >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
> --
>
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE
> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>       Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>
> --
>
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE
> <https://www.google.com/maps/search/2218+University+Ave+SE?entry=gmail&source=g>
>       Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>
> --
>
> ---
> Nick Buraglio
>
> Planning and Architecture
> Energy Sciences Network
> [phone]
>
> _______________________________________________ v6ops mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/v6ops
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>