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

[Brian E Carpenter <[e-mail]>]

On 26-Apr-22 12:51, George Michaelson wrote:
> I'm having tremendous deja-vu about at meeting at MV where Google was tracking IPv6 deloyment (this would be 15+ years ago) and somebody from PCI-DSS was telling me IPv6 would never meet their compliance needs and we misunderstood the standards imperative, if we thought IETF had any influence on how they certified needs in this IP space.
> 
> Somehow I think the world has orbited a good number of kilometers, without significant change in mutual understanding.

About 15 orbits round the Sun, I suspect. Hence, exactly, my question whether it's time to update RFC4864.

    Brian

> 
> _G
> 
> On Tue, Apr 26, 2022 at 10:48 AM Nick Buraglio <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     My experience is pretty dated from my prior job, so take this with that caveat, but my understanding of PCI-DSS is that the “functional requirements” are highly interpretable and almost wholly up to the auditor discretion.
>     For example, In the environment I was in the auditor deemed that VLAN ragged segregation was insufficient and that he required us to use a VRF. This was non-negotiable from the answers to my inquiry.
>     I was told that Campuses almost exactly like ours with similar architecture but different auditors used VLANs just fine. We were also required to have an IPS when a passive IDS would have been completely sufficient.
> 
>     Compliance doesn’t generally care about technology implementation, just risk mitigation.
> 
>     On Mon, Apr 25, 2022 at 19:38 David Farmer <farmer=[e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]>> wrote:
> 
>                 You want to look at PCI DSS 3.2 requirement 1.3.7.
>                 image.png
> 
>                 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] <mailto:[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] <mailto:[e-mail]>>
>                      > *Sent:* Sunday, April 24, 2022, 11:27 PM
>                      > *To:* Kevin Myers <[e-mail] <mailto:[e-mail]>>
>                      > *Cc:* Brian E Carpenter <[e-mail] <mailto:[e-mail]>>; Erik Auerswald <[e-mail] <mailto:[e-mail]>>; Ted Lemon <[e-mail] <mailto:[e-mail]>>; v6ops list <[e-mail] <mailto:[e-mail]>>; 6man list <[e-mail] <mailto:[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]> <mailto:[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]> <mailto:[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]> <mailto:[e-mail] <mailto:[e-mail]>>>; Erik Auerswald <[e-mail] <mailto:[e-mail]>
>                     <mailto:[e-mail] <mailto:[e-mail]>>>; Ted Lemon <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>
>                      >     Cc: v6ops list <[e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>>; 6man list <[e-mail] <mailto:[e-mail]> <mailto:[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]>> <mailto:[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]> <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>> <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]> <mailto:[e-mail] <mailto:[e-mail]>>
>                      > https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops> <https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>>
>                      >
>                      >
> 
>                     _______________________________________________
>                     v6ops mailing list
>                     [e-mail] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> 
> 
>                 -- 
>                 ===============================================
>                 David Farmer Email:[e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>     -- 
>     ---
>     Nick Buraglio
>     Planning and Architecture
>     Energy Sciences Network
>     [phone]
>     _______________________________________________
>     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
>