Hesham, It sounds to me this brings no real value to IPsec. You must be seeing something I don't could you please state why your so supportive for this change and what are your technical reasons that will add value for IPv6?
Thanks /jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Soliman, Hesham > Sent: Saturday, September 11, 2004 8:04 PM > To: [EMAIL PROTECTED] > Cc: Brian Haberman; [EMAIL PROTECTED] > Subject: RE: AH and flow label > > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
