Le 2012-04-11 à 17:54, Maoke a écrit : > > > 2012/4/12 Rémi Després <[email protected]> > > Le 2012-04-11 à 15:44, Maoke a écrit : > >> >> postpone other parts, but focus on the checksum issue. >> 2012/4/11 Rémi Després [email protected] >> >> 5.4 Impact c. - it is true that, in the IPv6 packet of a tunneled ICMPv4 >> message, the ICMPv4 checksum doesn't ensure IPv6 address integrity. But this >> integrity can be ensured at tunnel exit by checking that CNPs do preserve >> checksum neutrality. This can be clarified by a complement in the 4rd-u >> security section. >> >> >> 1. this introduces another new semantics/logic of protocol stack processing >> at exit CE. it is really hard to call it either IPv4 or IPv6. > > How it is called is IMHO secondary, what is a fact is that it ensures address > security. > >> 2. even though this CNP works for the address integrity, > > (which was the listed point) > >> unfortunately, however, the checksum still provides integrity protection for >> packet length and payload protocol type in both IPv4/ICMPv4 pair and >> IPv6/ICMPv6 pair. they are involved either in IPv4 header checksum or in >> ICMPv6 checksum, which covers the pseudo-header of IPv6. > > >> how could CNP protect these? > > No way, of course. > (Are we now in the technical discussion, or still in deliberate controversy?). > > > technical discussion results in problem understanding instead of certainly a > support for or an objection to a work politically. so i don't understand what > is the so-called "deliberate controversy" here.
I supposed it was evident to you too that CNP cannot protect protocol and/or packet length. Then, asking how it would do that sounded to me as a non technical question. Sorry if this wasn't the case. > i suppose my draft is written very neutral. Full of good level technical analysis, I am pleased to acknowledge. Although I believe anyone asked to guess whether you are in favor of 4rd or MAP would easily find the answer, I can also acknowledge that the draft is neutral to a good enough extent. > as you raised a new solution regarding a concern while i found it not > complete, i surely need to confirm if you would design a more comprehensive > solution for that issue, and if the already-designed mechanism has had the > functionality but i was not aware of that. >> thanks for mentioning CNP here. > >> i need to modify the concern for "address integrity" to the concern for >> "integrity of addresses, packet length and payload protocol type". > > - Addresses have been covered AFAIAC. > - No test scenario I can imagine can reveal an ICMPv4 security problem > concerning protocol type or packet length. (A simulated hardware failure > would AFAIK be needed, and with that, many other security problems can be > considered to exist.) > > => Unless you come up with new facts, end of this subject for me. > > > i don't think it is needed to provide new facts here, at this stage. > the test scenario is the next step. OK. > the draft is purposed on clarifying these semantics and their direct impact. > judgment on the severity of the impacts is remained to the readers. OK. > i don't think 4rd-u is scoped within networks with reliable L2 links, isn't > it? It is scoped under the common assumption that: (1) L2 isn't reliable in that it can loose packets; (2) L2 is reliable in that it never delivers corrupted packets without corruption being detected. AFAIK, IPv6 has been specified under this assumption. RD > then, in a generic physical environment, one may think only address checksum > is enough, one may think it is not enough, one may think checksum is anyway > too weak to provide so-called protection, etc. --- all of these sort of > asserts of severity judgment are out of the scope the draft (sec 5 para 1). > > fine to close this subject for me too because you have clarified "no way". > that's enough. a refined statement on this issue will appear in the revision. > > tomorrow let me clarify another. > > thanks, > maoke > > > > RD > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
