Subject: RE: AH and flow label

From: "Soliman, Hesham" <[email-masked]>
Date: Sat, 11 Sep 2004 20:04:15 -0400

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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Sun, 12 Sep 2004 10:53:53 +0200

In your previous mail you wrote:

   >we have to assume our previous inconsistencies.
   
   => What is the counter argument??

>> it breaks the compatibility in an invisible way.

   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??
   
>> because there is an immediate drawback and it will be an
irrevocable decision (until AH vX, X >= 4).

   >in fact in general there is even no API to get the received flow label!
   
   => That doesn't mean it can't happen.

>> this means this benefit is virtual.

   
   
>> the same than proposed by the people who want to deprecated AH:
ESP in tunnel mode. It adds more bits but provides protection of
the whole IP packet.

   
>> AH was deprecated at least once at an ipsec WG session at an IETF
meeting. Fortunately the decision was forgotten (I don't know how/why,
perhaps the fact the ipsec WG worked without minutes and from time to
time without published agendas had good consequences :-).
If you look at the ipsec WG mailing-list archives, the deprecation of AH
or of one of the two (transport/tunnel) modes is a frequent troll subject,
like the better than text format for RFCs in the ietf list.

Regards

[email-masked]