I agree with the drawback you see and it's not ideal. But I also think the whole flow label story was inconsistent and we finally have concensus on how we want to use it.
> => this is something we should not reproach the ipsec WG for... => I wasn't reproaching the IPsec WG. Please don't put words in my mouth or email! Given the fact that it is immutable, it makes a lot of sense to protect it. >=> this is a "make it prettier" weak argument, i.e., >we have to assume our previous inconsistencies. => What is the counter argument?? Stephen Kent already mentioned that this is not a change to the older version of AH. So if all the benefit you can see is that it makes things "prettier" and consistent then why not?? The benefit depends on the application. In cases where the value of the flow label is used for any type of decision making related to routing or QoS (in an end host) it is very important to make sure that it was not modified by MITM. Today there is no way of knowing this. >=> as only the destination can check the ICV, the application must >both be at the destination, not on an intermediate node, and need >a per packet protection of the flow label. I don't know such application, >in fact in general there is even no API to get the received flow label! => That doesn't mean it can't happen. There was no API to support v6 a few years ago. We can enable this feature and it can be used by anyone in future. I have several ideas in mind for using the flow label. >=> many of us have, but not one implying the usage of AH. => Francis, I'm sure you know that if anyone tries to standardise a mechanism that uses the flow label e2e and requires it to be secure IPsec is the only way to do it. Do you have other alternatives? >In fact the last time AH was nearly deprecated we didn't find >convincing cases where the extra protection provided by AH >was really an advantage... => I didn't follow those arguments and AH is obviously not deprecated so it makes sense to keep things consistent in standards. One of those was published in the flow movement draft. So if the above is too abstract please see draft-soliman-mobileip-flow-move for an example. >=> I've looked at the (expired) document: there is no security considerations >so no recommendation to use AH. And when I try to build an argument >I get two cases: - end-to-end flow movement (i.e., with routing optimization): the classic 5-tuple works and is even better because for instance it supports wirdcards. => The flow label option saves more bits over the air, which is quite important for wireless networks. Hesham =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
