In your previous mail you wrote:
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??
>> 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).
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.
>> this means this benefit is virtual.
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?
>> 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.
>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.
>> 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 PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
