On Tue, March 27, 2012 2:35 am, Tero Kivinen wrote: > Dan Harkins writes: >> I guess I'd like to register an objection. I wrote a draft a few >> months >> ago to address this: >> >> http://www.ietf.org/id/draft-harkins-ike-iana-update-00.txt >> >> That suggested making it "Specification Required". You mentioned that >> someone was opposed to it being "Specification Required" but didn't say >> who or what the rationale was behind that opposition. >> >> So I'd like to discuss this a bit. I prefer "Specification Required" >> and would like to know what the problem someone has with it is. > > See the orignal thread in the ipsec-list: > > http://www.ietf.org/mail-archive/web/ipsec/current/msg07428.html
OK, but that says "'Specification Required' or 'IETF Review'", it's not opposition to "Specification Required". > What is your objection to the IETF Review? Well, I feel it is setting the bar too high for what I want to do. I had to remove a chunk of text from my PAKE draft fixed a significant, know, serious, and continuing problem with IKEv1. I was told that I should write another I-D that includes that text and try to see what happens. The issue is that requiring IESG review and AD sponsorship will likely result in me not getting over that bar and getting a code point assigned. It appears that all the PAKE drafts got one "yes" from the sponsoring AD and the remaining votes were "no objection" so it doesn't seem like the IESG is really interested in this topic and, frankly, I think the majority think "that stuff is out of my field of expertise". So my only option is to cajole an AD into sponsoring my draft and hoping that no one else on the IESG objects by saying, "didn't we just do this?" I don't want to burn up what remaining goodwill I might have with our ADs by continuing to push this topic. That said, the problem I want to fix-- IKEv1's susceptibility to dictionary attack, it's binding of a PSK to an IP address, and the prevalence of XAUTH because there's no other option-- should be fixed. We can say, "stop using IKEv1" but giving someone the option of implementing PAKE + IKEv2 versus just implementing PAKE, or more likely just continuing on with a broken XAUTH deployment, we all know what they'll do and it's not doing PAKE + IKEv2. It would be a service to the Internet to provide a fix for this. The IETF has not been successful in forcing people to do things against their will (viz, the history of IPv6) and if we tried here we'd likely fail again. So let me turn it around, what's wrong with "Specification Required"? thanks, Dan. >> > IETF Review - (Formerly called "IETF Consensus" in >> > [IANA-CONSIDERATIONS]) New values are assigned only >> through >> > RFCs that have been shepherded through the IESG as AD- >> > Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The >> > intention is that the document and proposed assignment >> will >> > be reviewed by the IESG and appropriate IETF WGs (or >> > experts, if suitable working groups no longer exist) to >> > ensure that the proposed assignment will not negatively >> > impact interoperability or otherwise extend IETF protocols >> > in an inappropriate or damaging manner. >> > >> > To ensure adequate community review, such documents are >> > shepherded through the IESG as AD-sponsored (or WG) >> > documents with an IETF Last Call. >> > >> > Examples: IPSECKEY Algorithm Types [RFC4025], >> > Accounting-Auth-Method AVP values in DIAMETER [RFC4005], >> TLS >> > Handshake Hello Extensions [RFC4366]. > -- > kivi...@iki.fi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
