>Why do you think this is important and what problem does it solve?
This appears to be the key. Maybe I am missing something, but aren't flow labels possibly looked at and used at hops in between the src and dst? If the flow label is changed/hacked along the way, isn't the damage (not going to try and quantify damage here because that really depends on what the hops do based on the value) already done before the destination is in a position to determine if the packet is compromised? If 100% security is desired, then somehow the flow label needs to be verifiable at each hop (in the hop by hop header). Not sure how likely this is.
So while it seems like a good thing to protect this field in the ICV computation, I am not sure that any value that can be realized is worth the potential of incompatible versions not being able to communicate in a secure way when flow labels are being used. If you do want to change the spec, then maybe another option is needed that tells the DST if the flow label is being included in the ICV or not.
--rich
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.
However, as I noted earlier, there was no stated requirement that the old and new versions of AH be interoperable, although they could be, in principle, if we did not make this change.
Steve
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
