On Mon, Oct 24, 2011 at 1:38 PM, Doug Arnold <[email protected]> wrote: > This debate has been going on since before the PTP v2 standard was released, > and the consensus in the timing community agrees with you. Timing packets do > not need to be encrypted. Authentication would be a more appropriate > security mechanism, since time is not a secret. There is even an > experimental authentication mechanism in the standard, as you suggested (See > Annex K of IEEE 1588-2008). > > Nevertheless, there is a requirement for PTP over IPsec. The reason is that > some system architects/admins want to have a policy that all packets go > through the IPsec tunnel. We timing geeks like to think of PTP as special, > but to many system architects it is just one of many management protocols > that run on their network. They don't want the complexity of making an > exception for one protocol.
There's no reason to agree to a bad architecture just because it appears to be written in stone. Agreeing to document it on account of its being deployed is another story, but there's no requirement that we do that either. Timing packets *should* need no more protection than the outer IP headers on an IPsec-protected packet (hello) or than the cleartext bits of IKE. Some things have to go in the clear. So much so -so much so!- that the proposal on the table is to make enough of the timing packets go in the clear that the end nodes can get more accurate time. Imagine that. What better proof is there that the architecture is broken? But does PTP need protection? Or would it need any modifications/extensions to make it safe to use without IPsec? You didn't clarify this. It may well be easier for IPsecme WG and the IETF to agree to the proposal than it would be to fix PTP if it needs fixing, but it'd be nice if we could establish that too. This is the sort of homework that the proposal's proponents should be doing. > TICTOC could make a big push to educate the system architects that ptp should > not be encrypted. We could even convert some of them, but not all of them. > The only thing that could kill this requirement is if we convincingly show > that ptp over IPsec could absolutely not be made to work in wireless backhaul > networks. I don't think that such an argument is forthcoming. If TICTOC WG won't say "no" then the maybe IPsecme WG, the IETF, and/or the IESG will. I guess we're about to find out what IPsecme thinks of this. > GET OVER IT EVERYONE, THE REQUIREMENT FOR PTP OVER IPsec IS NOT GOING AWAY! > We need to figure out how to make it work as well as it can. There is no requirement that the IETF rubber-stamp this either. Using caps won't help achieve consensus. Now that the issue is clear, I think we could actually work towards establishing consensus on one or another proposals, or even simply show that there's consensus for none if that's what happens. As part of this process it'd be useful to find out what the process might be to change the femtocell architecture so as to remove the requirement that timing packets be encrypted. What if the IETF consensus is that the femtocell architecture should be changed? Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
