>> Generally, we'd need new documents if there are significant features which >> have NEVER been useful/implemented, and we should drop them first. >> (I think that all of AH might fall into that, sadly) > > I have tried to kill AH a number of times and failed. I don't think we > can strip it out of 430x documents, sadly. I think with IPsec being > deployed throughout internal non-internet connected structures, we > couldn't really evaluate its deployment well anyway. But perhaps any > new variants (like the EESP we are talking about now) could try harder > to not specify AH variants.
Like some others, I’ve been around when AH was designed. Its main (only?) purpose was addressing Crypto Export Control that required making exportable code impossible to hack to enable encryption (while maintaining compliance with standard). Hence, “Authentication-only Header”. I daresay that now AH is dead, used only by “less-clued”. It does not make sense to continue resuscitating AH anymore (for the last decade or so).
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
