At Wed, 20 Aug 2014 18:26:01 -0300, Fernando Gont <[email protected]> wrote:
> [...] The one you suggested addresses > only one of the two kinds of translators (if I understood correctly), > and may still leave the door open in some scenarios. Specifically? > > And, while the SIIT-kind of spec may have to be revised > > because of this issue, we can still allow experimental/serious > > deployment of it at their own risk. > > It's really "deployment at someone *else's* risk". Because it's the > folks that generate atomic fragments the ones paying the price (and not > the SIIT boxes or deployments). If the deployment/experiment of SIIT is real but we still ban PTB<1280 as a first step of revision, they (= someone *else*) will need to pay some price anyway: either they can be susceptible to the DoS in question or they can see some strange failure when IPv4 fragmentation is needed. Certainly, we should fix SIIT(-kind) of translators for a longer term. So it seems to me the question of which kind of cost we ask "them" for paying until then. I thought the gradual approach would be less controversial than an abrupt ban and allow us to use our time more efficiently, so I mentioned it (I actually didn't intend to "suggest" it, as I personally don't have a strong stake on it). I know you have a different opinion and I respect that. I just wish it would be accepted smoothly. > > I personally have no problem with deprecating atomic fragments (which > > would also deprecate PTB<1280 naturally); I'm not relying on SIIT > > myself nor I have any incentive to defend it in general. So, if > > others are also happy with that I'll be too. But as this thread > > actually shows, a proposal of deprecating something can often be > > controversial since it can break some existing deployment, and it's > > basically impossible to prove there's no such deployment (and the > > acceptable deployment level to justify the deprecation is often a > > matter of opinion). > > What breaks what may vary from one case to another. For instance, > relying on atomic fragments implies that you rely on: > > 1) Both ICMPv4 and ICMPv6 messages not being filtered > 2) IPv6 fragments not being filtered > 3) Nodes reacting to ICMPv6 PTB<1280 > > Both 1 through 3 vary from one environment to another... but I'm of the > idea that the lest you rely on them, the better. Same as above. It just seems to be that we have different expectations on the feasibility of options from different point of views. As you still seem to believe your preferred option is more feasible in terms of the standardization process, I have nothing more to say; I have no reason to push the alternative I mentioned, so please simply ignore it and try to persuade others. -- JINMEI, Tatuya _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
