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

[Nick Buraglio <[e-mail]>]

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]>
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.
>>> [image: 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]> 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
>
-- 
---
Nick Buraglio
Planning and Architecture
Energy Sciences Network
[phone]