On Mon, Oct 24, 2011 at 6:19 PM, Doug Arnold <darn...@symmetricom.com> wrote: > I don't agree that it is incumbent on those preparing a draft on PTP over > IPsec to show the need. The wireless system architects have already said > they want this. If someone disagrees, they are the ones who need to explain > why an exception for timing is necessary.
Really? So, just publish any I-D and don't show why it's needed, just by dint of submitting your I-D you get to have volunteers review your I-D and ultimately have an RFC published? I don't think so. I-D authors do need to justify their proposals. Their justification *can* be "we have no choice because this other standard development organization left us no choice", but it has to be stated -- certainly when that is their motivation, and especially if there's also any controversy as to the proposal. > You raise the possibility of the IETF as a whole taking a stand on > architecture. This would certainly carry a lot more weight than a stand by > one obscure WG, TICTOC. Such a stand happens sometimes, around big issues. > For example, the IETF has taken a stand that security shall be implemented > via IPsec, and not with separate mechanisms for each application, such as > https. The IETF has taken a stand promoting IPv6. (note: IPv4 and https > persist despite these stands.) I'm pessimistic, though, about the possibility > of convincing those high up in the IETF organization that encrypted PTP is a > big enough issue for the IETF as whole to weigh in on. At the very least > they are likely to say that we haven't tried hard enough to make this work > yet. This is basically the same problem that we have with network architects. > Timing is a very small part of the big world of networking. No, I raised the possibility that the IPsecme WG and IETF might not reach consensus of publishing the proposal on the Standards-Track or any track. There may not be any need to take a stand on the issue -- the I-D requires consensus to progress, and may not be able to obtain it. The IESG can take a stand, as can the IAB in an appeal. But long before we get there it's perfectly fair for participants to question the proposal and propose alternatives. In any case, the IETF didn't say "we won't standardize SSL/TLS because IPsec is what should be used" or anything of the sort. The IPsec vision for end-to-end security certainly has failed, and IPv6 has not yet dethroned IPv4 -- all true, but that says nothing about the current issue other than that you can put together a strawman :) > However, you have brought up an interesting possibility. The IPsecme WG > might be persuaded to create an option for leaving timestamps in the clear, > in some fashion. If such a thing were implemented in a future version of > IPsec, then the system architects who want everything to run through the > tunnel would likely be mollified. This is probably the best long term > solution. I expect that IPsecme WG would want to see something written down > that quantitatively documents the advantage of not encrypting time, either in > terms of hardware cost or timing performance on the same hardware. At least > to the level of a paper study or simulation. Since you have passion for > this, perhaps you would like to start a draft of such a document? Did I bring that up? I did not. However, there is an interesting idea: fold PTP/NTP into IKE, then it will be easy to timestamp all IKE packets (since there should be so few IKE packets compared to ESP)! Bonus: the timing packets can be fully encrypted and not be identified as such. Nice try on volunteering me though! :) > Even if the IPsecme WG were persuaded to address this, It would probably take > a while before it was in the field in servers and routers. I predict that > there will be a "lock-out spec" for encrypted PTP from at least one major > wireless infrastructure company sometime soon. And those of us who sell to > them are either going to build it, or lose the business to someone who will. > And if the IETF won't define it then the ITU, IEEE or someone other > organization will. I suggest that the IETF is the organization which is best > suited to define PTP over IPsec, since the IETF controls IPsec. Isn't that true of the proposed WESP extension as well? In any case, if the proponents don't care if the IETF blesses their proposal then why not just not bother? If many proposals rejected here are simply standardized elsewhere, why bother coming here at all? Or why bother standardizing anything? I submit that the reason why one should bother is that the IETF has significant brand value and significant value in getting *others* to implement valuable ideas, and part of that value surely derives from having the sort of review that does sometimes lead to a decision (or lack of consensus) to not publish some proposal. I'm not scared by threats of going elsewhere, especially when the authors haven't made such threats in the first place. I don't see why the proponents should be scared of rejection by yours truly either, since my opinion is hardly the determinant of consensus here. Proponents should be more concerned by the relative silence of many of the key IPsecme WG participants. > One last thing, I promise, no more all caps statements. Thanks! :) Nico -- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
