On 08/20/2014 10:07 PM, 神明達哉 wrote: > 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?
Well, you can only really apply the suggested check to the stateless translation scenario. But since a host does not now where it will be deployed, it cannot (out of the box) require that e.g. ICMPv6 PTB<1280 use any specific part of the address space. Put another way, the mitigation would not "just work out of the box" for any of the servers running on the public Internet. And then, for the scenarios "a" or "c" from Section 2 of RFC6144, you still need to enforce filtering to prevent attacks within the IPv6 network. >>> 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. Reading though RFC6145, I see that in quite a few places the spec considers "configuration options" and the like t be able to cope with IPv6 packet drops, and fragmentation -- but for a different than security (the ones that I've mentioned below). For instance, Section 6 of RFC6145 says: Two recent studies analyzed the behavior of IPv6-capable web servers on the Internet and found that approximately 95% responded as expected to an IPv6 Packet Too Big that indicated MTU = 1280, but only 43% responded as expected to an IPv6 Packet Too Big that indicated an MTU < 1280. Put another way, we are leaving the door open to attack due to something that is giving us a 60% failure rate already. > 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 Just a request for clarification: The "gradual path" would be to enforce additional requirements on the ICMPv6 PTB messages? >> 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 no idea about which options is "more feasible in terms of standardization process", to be honest. For the time being, I'm just rethinking/re-evaluating options, even if just for the technical/mental exercise of figuring out what would be the best approach. And kind of hope that if the analysis is correct, that may result in "feasibility in terms of standardization process". -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
