ipsec October 2011 archive
Main Archive Page > Month Archives  > ipsec archives
ipsec: Re: [IPsec] [TICTOC] Review request for IPsec security fo

Re: [IPsec] [TICTOC] Review request for IPsec security for packet based synchronization (Yang Cui)

From: Bhatia, Manav (Manav) <manav.bhatia_at_nospam>
Date: Wed Oct 19 2011 - 11:50:54 GMT
To: Tim Frost <tfrost@symmetricom.com>, Nico Williams <nico@cryptonector.com>

Hi,

I had spoken to one of the initial authors of this IPsec draft and I was told that setting up an Ipsec tunnel exclusively for shipping 1588 may not be possible in the femto architecture. They are thus trying to use WESP (that I have co-authored) to identify 1588 packets within an IPSec stream.

I have tried to describe the problem that this draft is attempting to address here:

http://www.ietf.org/mail-archive/web/tictoc/current/msg00755.html

As an author of WESP I can say that the way this draft uses WESP to protect 1588 is not very appropriate. The draft tries to add some additional identifiers in each protocol packet to uniquely identify 1588 packets. This in the security land will not be accepted as anybody snooping on the wire will be easily able to disambiguate 1588 packets from other packets in the stream. If the authors want to use WESP then they must negotiate this unique ID (or a set of IDs) in IKE and pad the packets randomly so that the attackers cant identify the 1588 packets in the Ipsec stream.

Cheers, Manav

> -----Original Message-----
> From: tictoc-bounces@ietf.org
> [mailto:tictoc-bounces@ietf.org] On Behalf Of Tim Frost
> Sent: Wednesday, October 19, 2011 3:57 PM
> To: Nico Williams
> Cc: cuiyang@huawei.com; ipsec@ietf.org; TICTOC@ietf.org;
> Paul_Koning@Dell.com; mills@udel.edu
> Subject: Re: [TICTOC] [IPsec] Review request for IPsec
> security for packet based synchronization (Yang Cui)
>
> Nico,
>
> I am not an author of this draft, so I don't propose to
> defend the contents. I was merely pointing out that those
> people criticizing it on the basis that encryption of timing
> packets was unnecessary were missing the point, which was
> that timing packets are encrypted because the 3GPP
> architecture says they must be, so we have to work out how to
> deal with that.
>
> I think your revised abstract is good and explains the point
> clearly; I would recommend that the authors take note of this
> in the next revision.
>
> Tim
>
>
> -----Original Message-----
> From: Nico Williams [mailto:nico@cryptonector.com]
> Sent: 18 October 2011 20:14
> To: Tim Frost
> Cc: Paul_Koning@Dell.com; mayer@ntp.org; ipsec@ietf.org;
> mills@udel.edu; TICTOC@ietf.org; cuiyang@huawei.com
> Subject: Re: [TICTOC] [IPsec] Review request for IPsec
> security for packet based synchronization (Yang Cui)
>
> On Tue, Oct 18, 2011 at 10:37 AM, Tim Frost
> <tfrost@symmetricom.com> 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
> --
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec