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

[Kevin Gross <[e-mail]>]

Thanks for the review. Responses below.

On Thu, Nov 8, 2012 at 4:40 PM, Magnus Westerlund <
[e-mail]> wrote:

> 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.
>

Ok.

>
> 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?
>

A common system behavior is that when the NTP clock is
frozen, successive calls to retrieve system return incrementally larger
time values. This keeps applications from faulting from assumptions about
time being continuous and monotonic. This behavior occurs in the LS bits of
the time value and so is not generally visible in the human-readable format
shown in the table. I can add a discussion of this if you think it is
useful.

>
> 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.
>

That's a good point. If we need to keep sending SRs during the 2second leap
second interval to avoid timeouts, they can be sent with a 0 NTP timestamp.
This might be a better approach for all RTCP rates. I have to research what
special receiver behavior may be required to accommodate this.

>
> 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?
>

Today I volunteered to review draft-ietf-tictoc-security-requirements. I
will take this and your comments into consideration and try to improve the
security considerations section.
>
>
> 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.
>

Sounds like I need to look at dividing informative vs. normative
references.

>
> 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]
> ----------------------------------------------------------------------
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>