[AVTCORE] Comments on draft-ietf-avtcore-leap-second-01

[Magnus Westerlund <[e-mail]>]

Hi,

I have reviewed the leap second document and have the following comments.

1. Section 1. It needs to say also in the introduction that it updates
RFC 3550, not only in the abstract.

2. Section 3.4:
   +-------+--------------+--------------+--------------+--------------+
   |  RTP  |      TAI     |      UTC     |     POSIX    |      NTP     |
   +-------+--------------+--------------+--------------+--------------+
   |  8000 | 00:00:32.500 | 23:59:58.500 | 23:59:58.500 | 23:59:58.500 |
   | 12000 | 00:00:33.000 | 23:59:59.000 | 23:59:59.000 | 23:59:59.000 |
   | 16000 | 00:00:33.500 | 23:59:59.500 | 23:59:59.500 | 23:59:59.500 |
   | 20000 | 00:00:34.000 | 23:59:60.000 | 23:59:59.000 | 00:00:00.000 |
   | 24000 | 00:00:34.500 | 23:59:60.500 | 23:59:59.500 | 00:00:00.000 |
   | 28000 | 00:00:35.000 | 00:00:00.000 | 00:00:00.000 | 00:00:00.000 |
   | 32000 | 00:00:35.500 | 00:00:00.500 | 00:00:00.500 | 00:00:00.500 |
   +-------+--------------+--------------+--------------+--------------+

                                  Table 1

I am wondering if the RTP 20000 and 24000 is really correctly
representing what you write in section 3.2 for the NTP column. Should't
the 00:00:00.000 actually  00:00:00.000-, i.e. something that is prior
to 00:00:00.000 but just?

3. Section 4.1:

   RTP Senders working to a leap-second-bearing reference SHOULD NOT
   generate sender reports containing an originating NTP timestamp in
   the vicinity of a leap second.  Receivers SHOULD ignore timestamps in
   any such reports inadvertently generated.

I wonder how you in practice are going to fulfill the sender
recommendation. That only works if your regular reporting interval is on
the order of a second or longer. Otherwise not sending a SR packet for a
RTP packet sender within 1.5*Td (where Td is your deterministic
reporting interval) will be counted towards source time-out or other
methods detecting missing packets. So for a reporting interval of 100 or
200 ms you can't actually follow the SHOULD.

4. Section 5. Security Consideration.

I wonder if this section really are covering some potential issues.
First are there security replay mechanisms that uses the clock? SRTP is
not effected as it uses packet index, i.e. roll over counter + seq_nr.
But there might be other things that could be confused for example by
the posix clock.

Are there attack vectors that are created when by possibly fool an
end-host to believe a leap-second event is happening and thus thinks the
clock are freezing or repeating that otherwise would be possible?

5. Reference section:

I don't believe that all references are normative. I think for example
the note in section 3.0 uses [3] in an informative one. Additional ones
may be similar. Please check the usage of all the references if they
really are normative.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------