My previous comments about two-step took into account only the transmitter. Of course the the receiver needs to timestamp arrival times. Most hardware does this by recognizing packet format, a strategy that would be thwarted by encryption. It is my understanding that some network hardware timestamps all packets attaching a hardware-generated timestamp to each receive queue entry. That's what seems to be required here. This type of hardware combined with two-step sync announcements (apparently supported by both 1588 and NTP) could make for a workable solution.
Kevin Gross On Tue, Oct 18, 2011 at 9:37 AM, Tim Frost <[email protected]> wrote: > I think most of the reviewers are missing the point of this draft. > > The point is not that the timing packets are inherently secret and need > encryption, but that the 3GPP architecture mandates that EVERYTHING flowing > to the femtocell must be inside a secure tunnel, whether the security is > needed or not. It's a wider architecture issue, not the issue about whether > encryption is needed and how best to do it. > > The key figure from the draft is Figure 1: > > +-------------+ > | | > | Femtocell |<-----------------------------+ > | | | > +-------------+ | > | > | > /---------------------\ > | | > | Public Network | > | | > \---------------------/ > | > | > +------------+ +-------------+ | > |Clock Server|---------->| | | > +------------+ | | | > | Security GW |->---+ > +------------+ | | > |Femto GW |---------->| | > +------------+ +-------------+ > > > Figure 1. Typical Architecture of a Femtocell Network > > 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. > > 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. > > We could argue that 3GPP should never have mandated this type of > architecture, but we would be better off arguing that at 3GPP, not here in > IETF. > > Tim > > >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
