James Kempf wrote:
If AH is not heavily used today (or used at all), then why is there a backward compatibility issue with modifying it to protect the flow label? And, if AH may potentially be deprecated in the near future, then what is the point of discussing whether to add protection for the flow label in the first place?
(I dislike making even a small deployed base incompatible.)
One of the original applications for AH was security for RFC 2461, but, after trying that, SEND found out it didn't work and a different solution was adopted. Current applications for ESP are easy to identify, example: VPNs. Future applications are also, example: Mobile IPv6. What are the compelling current and future applications for AH? Note that I am not trying to disparage AH, but rather I'm looking for some practical justification for this thread.
You have a really good point about future use of AH. I also have trouble seeing why we should spend any effort on it. In fact, I'd rather simplify the whole architecture by dropping AH from RFC 2401bis- world; I realize that there are people who want to use AH for certain very specific applications. Those people can continue to use RFC 2402 if they want to. And all the people who would use AH would still be compatible with each other.
And I do believe the SEND experience was not exceptional; future IP "control protocol" protection requirements are likely to have similar requirements that make an AH-like function insufficient. There's been talk about creating a new general purpose security tool, to give IP control protocols what TLS has given for applications. But its not clear if that's feasible. In any case, AHv2 is unlikely (IMHO) the answer.
--Jari
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
