Tal,
I wasn't able to get meeting audio, so don't know whether this was
discussed.
My main concern with the draft concerns transparent clocks, as in
section 4.1.4. A PTP transparent clock is really just a Layer 2 or IP
forwarder with a timestamping mechanism based on a syntonized timebase.
Every forwarder on the master-slave path with significant queueing and
other variable delays must have the transparent clock mechanism, else
there will be loss of accuracy. Any forwarder can mount a MITM DOS
attack on a secured clock correction field by corrupting it. To say
nothing of greatly complicating the forwarding process and perhaps even
adding inaccuracy.
Which leads me to suggest that perhaps rather than trying to
authenticate the TC and protect the clock correction field as security
mechanisms in the PTP or its encapsulation might cause more problems
and risks than the threats they eliminates. Maybe it would be better
to think about this as a secure routing or signaling problem, and use
signaling or routing to constrain the set of feasible paths to those
which have a trusted, authenticated TC on each hop. This becomes a
problem for RSVP or LDP for the MPLS encapsulation, and OSPF and ISIS
for IP tunneling. I suspect (have not dug into it, though) that most
of the mechanisms we'd need already exist.
Dan
On 8/2/2012 12:10 PM, [email protected] wrote:
Date: Thu, 2 Aug 2012 19:10:39 +0300
From: Tal Mizrahi <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [TICTOC] TICTOC Security Requirements
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
http://tools.ietf.org/html/draft-ietf-tictoc-security-requirements-02
Following this week's TICTOC meeting:
1. We plan to release draft 03 within a month, and proceed to WG last
call.
2. Therefore, I will appreciate if people can send any comments they may
have by Aug 22.
3. There was some discussion about the "proventication" requirement. I
would like to suggest to change the terminology in the document, since I understand this
term is not very popular.
However, I believe that the requirement for a chain of trust is still an
important and valid requirement. Please comment if you think otherwise.
Thanks,
Tal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/tictoc/attachments/20120802/840b451f/attachment.htm>
------------------------------
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
End of TICTOC Digest, Vol 68, Issue 10
**************************************
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
