On Tue, Oct 18, 2011 at 10: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.
OK, but what's the point of WESP then? Is it simply to reduce the overhead on timing packets? Special handling of timing packets is claimed to be desired, but when I read the I-D I must have missed what the special handling was. Also, if the point can be made so succintly, then please make it so in the abstract. > The key figure from the draft is Figure 1: Doesn't help me. > 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. OK, so you want receive time to be tracked for timing packets as soon as the NIC interrupts the CPU, but you don't want to bother with this for all packets, just timing packets. Yes? Assuming I get this, then why not write the abstract so that it says all this. E.g., something like this: This document describes how to use Wrapped Encapsulating Security Payload (WESP) to carry timing packets, such as for the Network Time Protocol (NTP), such that they be may recognized as such early on during inbound processing. This allows end-nodes to easily track the time at which timing packets are received prior to decapsulation without having to do so for all encapsulated packets. Timing packets generally bear no confidential data, which means they do not require confidentiality protection. Finally, in the interest of performance, WESP is used without having to create additional SA pairs. The fact that Femtocell is the motivator doesn't seem that interesting. If this is a problem for Femtocell it's likely to be a problem for others. > 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. I don't understand this comment. Are these packets encrypted, or not? > 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. I have no problem with the architecture. I have a problem understanding what's actually being proposed. As to what I think the proposal is, I'm not sure that it's necessary, but I also don't have any objections (assuming I did understand correctly). Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
