On Wed, Oct 19, 2011 at 6:57 AM, Danny Mayer <[email protected]> wrote: >> The problem with this is once the packets have been encrypted, it is >> not possible for the femtocell to timestamp them on reception because it >> doesn't recognise them until after decryption, which is what this draft >> tries to address. > > You could always timestamp all packets and then worry about whether or > not you need the timestamp or is this prohibitive in cost?
That's my take as well. If you can timestamp some packets, you can timestamp them all. Perhaps the reading of a hi-res timer is a slow operation, or perhaps it can have deleterious effects. For example, a hi-res timer might be available only w/o reference to a single clock, with each hi-res timer being CPU core-/thread-specific, in which case the system would have to arrange for the packet to continue to be processed on the same core/thread even if it'd be better not to for other reasons. Modern CPUs can count CPU cycles though, which can be used as a good proxy for hi-res timers for relatively short runs of code, but perhaps tracking CPU cycles used to process a packet might require extensive changes to an implementation. Or perhaps some femtocells are implemented almost entirely in HW whose architecture makes it expensive to timestamp every packet. Details would be nice. As it becomes clear that this proposal is really a case of allowing local limitations of *some* implementations (possibly not even real limitations; details are missing, so we can't tell for sure) to bleed into protocol architecture, I'm now much more in the "this is not a good idea" camp. It might yet turn out that these limitations are much more universal than I imagine though. >> I totally agree with the comments people like Danny have made that > point out the difficulties that identifying timing packets just opens > them up to attack. However, comments attacking the rationale for > encryption are wide of the mark - the packets are encrypted by 3GPP > architecture, we have to work out how to deal with that. > > The rationale was attacked because it was not spelled out in the > document, it's as simple as that. The next question becomes is there a > better way to accomplish the goal given the architecture? I second this. The draft wasn't ready for review by the IPsec list. The result was bound to be either silence or skepticism. Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
