>Rich, > >For unicast flows, the commonly employed ICVs are based on symmetric >key management, and so it is unlikely that intermediate systems would >be able to verify the ICV. The MSEC folks have proposed public key >based ICV mechanisms that do permit verification en route, but these >are intended for multicast flows.
Thanks for the response and explanation. I guess in my earlier email I was getting what you just said. There is no way for intermediate systems to verify the ICV so if the flow label is hacked along the way it will not be detected until the end system verifies the ICV, which may be too late to stop whatever damage has happened. (I think someone else subsequently posted a similar analysis as well). Since the ICV is not going to protect guard against such problems, its inclusion in the ICV is really not going to buy us anything. If people think that including the flow label in the ICV is important, then I think what is being said is we need to know if the flow label is being maliciously changed inflight. If this is the case, then the ICV is not sufficient and we need an hop-by-hop solution. > >Steve --rich -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
