In your previous mail you wrote:
   
   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...

   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.

   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!

   I have several ideas in mind for using the flow label.

=> many of us have, but not one implying the usage of AH.
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...

   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.
 - home agent flow movement: the home agent is an intermediate node...

Thanks

[EMAIL PROTECTED]

PS: perhaps James Kempf (who supports you) has a good argument?

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to