Hi Manav, I think it's more important to clearly state what we want protocol designers to do/not do and why (ditto for IPsec implementers). We can figure out the process stuff later. I definitely think that it's worth spending time on drafting guidance about when (if ever) use of AH in new protocols is appropriate.
Thanks, --David +++ Sent from BlackBerry +++ ----- Original Message ----- From: Bhatia, Manav (Manav) [mailto:[email protected]] Sent: Saturday, December 31, 2011 08:53 PM To: Black, David; [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: RE: Moving Authentication Header (AH) to Historic Hi David and Yaron, I think its possible to edit the draft headers and the text so that we basically say that AH should NOT be used for newer proposals unless there is a burning reason to do so. And if someone wants to use AH, then they should have a pretty good reason for doing that. In my draft I clearly say that AH does a good job with whats its supposed to do - integrity verification. However, ESP-NULL does that equally good and there is no good reason to use AH any more. I wrote this draft because I was having a private discussion on PIM security with a few folks and the discussion started veering towards "Hey lets use AH since we want to snoop certain PIM packets and ESP-NULL wouldn’t let us do that". So, while people working on security understand that AH should not be used for newer protocols, there are lots of others who don’t. I just wanted that to be pointed out explicitly. I don’t really care whether its through an informational RFC, BCP, standards track or some other type as long as the message is out loud and clear. However, before spending any more cycles on it I would first like to gauge the interest level in the WG to see if people think it’s an idea worth spending time on. And if not, then why. Cheers, Manav -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Sunday, January 01, 2012 6:59 AM To: [email protected] Cc: [email protected] Subject: Re: [IPsec] Moving Authentication Header (AH) to Historic > I spent a few minutes trying to look up the precise definition of > "Historic Documents" in the IETF standards process. Since the > definition appears to be extremely vague and may not clearly apply in > this case, FWIW, the definition of "Historic" is in RFC 2026, and I agree with Yaron that it's not exactly precise: A specification that has been superseded by a more recent specification or is for any other reason considered to be obsolete is assigned to the "Historic" level. (Purists have suggested that the word should be "Historical"; however, at this point the use of "Historic" is historical.) There is a subtle distinction between Obsolete and Historic - an Historic RFC is always Obsolete, but an Obsolete RFC may not be Historic. Before going any further, let me say that I strongly agree with Yaron on priorities: > I strongly suggest that we avoid this rathole (and move to the next > one), by adopting the proposed wording below. Manav's I-D is an > Independent document and so its content is completely up to its > author; OTOH, I'd rather not waste the group's energy on > not-very-important process matters. What does matter is that > implementers and standards bodies understand the strengths and weaknesses of > our protocols. In order to obsolete AH, the draft header needs to say "Obsoletes: 4302", in addition to its discussion of making RFC 4302 Historic. Both of the foregoing require that the draft not be Informational; I'd go further and suggest that with suitable editing and review, this could be a Best Current Practice (BCP) RFC, as the primary goal is to document the following as current design practice: > > "AH should not be > > preferred when designing new protocols and all attempts must be made > > to use ESP-NULL" I believe that a BCP can be used to cause a standards track RFC to become obsolete. Thanks, --David ---------------------------------------------------- David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 [email protected] Mobile: +1 (978) 394-7754 ---------------------------------------------------- > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Yaron Sheffer > Sent: Saturday, December 31, 2011 2:26 PM > To: Dacheng Zhang(Dacheng) > Cc: [email protected]; Melinda Shore; Yoav Nir; Jack Kohn > Subject: Re: [IPsec] 答复: Moving Authentication Header (AH) to Historic > > I agree that people should prefer ESP-null for all new uses. > > I spent a few minutes trying to look up the precise definition of > "Historic Documents" in the IETF standards process. Since the > definition appears to be extremely vague and may not clearly apply in > this case, I strongly suggest that we avoid this rathole (and move to > the next one), by adopting the proposed wording below. Manav's I-D is > an Independent document and so its content is completely up to its > author; OTOH, I'd rather not waste the group's energy on > not-very-important process matters. What does matter is that > implementers and standards bodies understand the strengths and weaknesses of > our protocols. > > Wishing us all a Happy New Year 2012! > > Yaron > > On 12/31/2011 05:58 AM, Dacheng Zhang(Dacheng) wrote: > >>> If folks dont want to move AH to historic then perhaps this > >>> document could be modified to say something in the lines of - "AH > >>> should not be preferred when designing new protocols and all > >>> attempts must be made to use ESP-NULL" > > [Dacheng Zhang] > > Really like this suggestion. +1 > >>> Jack > > _______________________________________________ > > IPsec mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
