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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 8 Nov 2012 16:40:18 -0500

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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Kevin Gross <[email-masked]>
Date: Thu, 8 Nov 2012 17:05:51 -0500

Thanks for the review. Responses below.

> RFC 3550, not only in the abstract.

Ok.

> 2. Section 3.4:

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.

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

> 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.
> may be similar. Please check the usage of all the references if they

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

> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 9 Nov 2012 06:53:47 -0500

Hi,

Responding to the ones with question or feedback desired.

On 2012-11-08 17:05, Kevin Gross wrote:
> On Thu, Nov 8, 2012 at 4:40 PM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> 
>     2. Section 3.4:
> 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.

I think a short comment / note why this doesn't show up in the table
might be beneficial to avoid confusion in the reader.

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

I think using 0 makes it very clear that the NTP field is not to be
trusted for these packets. That is very clear for the updated and aware
implementation. It is quite bad for an old implementation. Using the
system clock across a leap second event can clearly result in a
desynchronization of audio and video with a second. If you use the 0
value a naive implementation can suddenly believe that the media is
desynchronized with 112+ years. I have seen this occur in at least one
implementation when feeding it bad time-synch data. The implementation
started buffering until it run out of memory.

> will take this and your comments into consideration and try to improve
> the security considerations section.
> 

Good, I encourage people to think creatively if there are ways of using
the rules provided for attacks. For example I think the insertion of 0
in the NTP field might have some implications.

Cheers

Magnus Westerlund