Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis

[Nick Buraglio <[e-mail]>]

On Mon, Mar 18, 2024 at 7:29 PM Ted Lemon <[e-mail]> wrote:

> On Mon, Mar 18, 2024 at 11:48 PM Nick Buraglio <
> [e-mail]> wrote:
>
>> > I think that was assumed in my comment—I was assuming that the problem
>>> is that the site is using the prefix assigned by the ISP.
>>>
>>> Yes. But in MHMP, there are two ISPs and two prefixes.
>>>
>>
> Right, and NPTv6 doesn't actually address this use case, because it's
> stateless. If you have a connection across the NPTv6 translator that is
> translated to ISP A's prefix, and then later another packet on the same
> connection goes out a different NPTv6 translator that is translated to ISP
> B's prefix, the connection is going to fail. So it's not at all true that
> this addresses the MHMP use case. What I think it does is make some
> problems go away, at the cost of creating subtle failure modes that will be
> difficult for users and even operators to reason about.
>

>
>> Not only that, but in the absence of guidance, a potpourri of random,
>>> almost certainly worse solutions will be created, deployed, and have no
>>> discernable or common support model outside of vendor lock-in or an
>>> otherwise inflexible proprietary solution. So the real question is "what is
>>> worse?". In the quest for ideal, we have trended toward vilifying what is
>>> tolerable even if it is imperfect.
>>>
>>
> This is a legitimate concern, but somewhat obviated by the apparent fact
> that people are already implementing the original version of this RFC and
> having success with it. What is the motivation to do more work? I'm not
> saying there isn't one—I'm suggesting making it explicit. I do not support
> changing the status of this document, so for me at least that alone is not
> a reason. If the document needs updating/clarifying, that's a good reason,
> but doesn't justify a status change.
>
I disagree

>
>
>> The requirement for obfuscation is, in my experience, not necessarily
>>> rooted in anything other than a bit of a misguided understanding of what
>>> middle box vendors and end user CPE touted as security - conflation of
>>> SPI + NAT44 == "Firewall". Like it or not, that has 25 years of tradition
>>> that has worked its way into compliance requirements (there are a myriad of
>>> threads on this in v6ops dating back many years) and worse yet the
>>> generations of engineers that were not around pre NAT44, which is most at
>>> this point, don't often consider a world without it. I say this not to make
>>> excuses or cases, but to simply illustrate that it is larger than "bad" or
>>> "good". It is just "current state".
>>>
>>
> Lorenzo has pointed out that a stateless NPTv6 doesn't actually hide
> internal addresses, so that's not a reason to do this work.
>

I am not making the argument that address obfuscation is a good reason. In
fact, I am fairly against that as a security mechanism because I feel that
it provides a false sense of security where there is nothing much more than
obscurity. However, that doesn't change the fact that there are compliance
requirements that do in fact have that incorrect assumption. I will fully
admit that this is a weak point, but it is also a reality of the enterprise
world.

> My point being, if we really are trying to produce something usefully
>>> different than what we already have with the NATted IPv4 Internet, we
>>> should make sure we are actually doing that. If IPv6 is just IPv4 with a
>>> wider address, we've already really done a lot of work we didn't need to do.
>>>
>>
>> That has been done. This is simply an implementation detail.
>>
>
> What is the "this" that's been done?
>
apologies for my lack of clarity - "this" ==  "something usefully different
than what we already have with the NATted IPv4 Internet"

>
> We agree on that. But we agreed on that 25 years ago *and we didn't solve
>>> it*.
>>>
>>> That's why I remain against NPTv6 going on the standards track, because
>>> it would still be nice to find a solution with no translation at all.
>>>
>>
>> I will say this - even with the experimental label this technology has
>> done two things and this is largely because it is tolerable, well thought
>> out, and solves a problem. It has:
>>
>> Made it into a very notable amount of both FOSS and high end commercial
>> hardware as a supported solution, and
>>
>> Been deployed in very large, high visibility production roles.
>>
>> If that does not illustrate something surpassing "experimental" then I
>> propose that those definitions are unclear to most folks that don't read
>> RFCs and drafts on a very regular basis and is counter to the definition:
>> "The "Experimental" designation typically denotes a specification that
>> is part of some research or development effort.".
>> The change in status simply recognizes that fairly indisputable fact. I
>> believe we have a "solution with no translation". Where the solution falls
>> down is in cases described as much, much larger issues that are seemingly
>> endemic - multihoming being an absolutely massive elephant in the room.
>> I would absolutely love for there to be a better way, and I will more
>> than happily move on when there is one. However, given what is available
>> *now*, leaving it as experimental will not slow the current support in
>> vendor implementations. It will also not prevent the deployment in the
>> cases where it does actually solve a problem. It's a pragmatic stop-gap
>> until / unless there becomes a more elegant answer.
>>
>> Would I personally prefer an answer that is not NPTv6? Sure. But I also
>> have deployed it *in production* because it is useful and solved a problem
>> that there was not a better solution for.
>>
>
> You haven't actually addressed the questions I raised earlier (not that
> you're required to, of course!). But the reason I posed those questions is
> that I don't think we have actually concluded an experiment. We don't
> actually know what this breaks. Great, there's FOSS that does this. Great,
> some folks have deployed it. What broke? Are the privacy issues I mentioned
> earlier addressed, or do the installations that use this simply violate the
> user's privacy? Etc.
>

I disagree that this experiment has been concluded.  My experiences in
deployment are that we've seen nothing broken. It does as we designed, but
I also work with a group of very, very clued engineers that don't use a
screwdriver as a hammer - they use the tools for what they are intended -
translating between two prefixes. Nothing more, nothing less. Personally, I
don't see this as a privacy mechanism any more than NAT44, that is to say
"not at all". It is a translation tool. It doesn't expose any more than a
typical GUA does, and does not protect any more or less than a 1:1 NAT.
It's certainly possibly to demonstrate broken behavior in nearly any tool
if the environment is either not conducive for success or of the tool is
used in such a way that is not an environment that the tool is designed
for, or more likely that there is some legacy application somewhere in the
network that does not understand contemporary protocol behavior.

>
> The fact that some people have deployed this and are happy they deployed
> it does not actually demonstrate that an experiment was done, or that the
> result of that experiment was that there were no issues, or even that
> whatever was done actually tried to explore the issues that this protocol
> raises.
>

Agreed, happiness should not determine success. From what I have seen
(which is admittedly limited) moving from experimental to a "higher level"
RFC is typically accompanied by something like a deployment status
document, e.g. the SRv6 deployment status doc here
https://datatracker.ietf.org/doc/html/draft-matsushima-spring-srv6-deployment-status

nb