Re: [secdir] Secdir last call review of draft-ietf-rmcat-video-traffic-model-06

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

Hello, 

Thanks to Yoav for your review and to Colin for chiming in with your comments. 

We authors have discussed over email regarding this section. We recently submitted the
updated draft (version -07).  The text has been revised as below to clarify that this draft
itself does not impose security concerns. Instead, it can be used for evaluating candidate
algorithms to prevent them from hurting the Internet: 

The synthetic video traffic models as described in this draft do not
   impose any security threats.  They are designed to mimic realistic
   traffic patterns for evaluating candidate RTP-based congestion
   control algorithms, so as to ensure stable operations of the network.
   It is RECOMMENDED that candidate algorithms be tested using the video
   traffic models presented in this draft before wide deployment over
   the Internet.  If the generated synthetic traffic flows are sent over
   the Internet, they also need to be congestion controlled.

Please let us know if the above revised version is sufficient in addressing your concerns. Further
discussions/suggestions are welcome. 

Best regards,
Xiaoqing (on behalf of all authors). 



On 1/24/19, 1:40 PM, "Colin Perkins" <[e-mail]> wrote:

    > On 24 Jan 2019, at 19:23, Yoav Nir <[e-mail]> wrote:
    > 
    > Reviewer: Yoav Nir
    > Review result: Has Nits
    > 
    > I have reviewed this document as part of the security directorate's ongoing
    > effort to review all IETF documents being processed by the IESG.  Document
    > editors and WG chairs should treat these comments just like any other last call
    > comments.
    > 
    > To quote from the abstract, the document "describes two reference video traffic
    > models for evaluating RTP congestion control algorithms". Indeed it does not
    > describe any protocol or algorithm that is going to get deployed on the
    > Internet, but rather a model for evaluating congestion control algorithm before
    > they are standardized or deployed. As such, I would not expect it to have much
    > to say on security, either good or bad.
    > 
    > It is conceivable that a congestion control algorithm would be exploitable by
    > an attacker. For example, some pattern of traffic might trigger such an
    > algorithm to block or slow down traffic for a victim. It may be a good idea to
    > evaluate whether such algorithms are conducive to such attacks. But speculation
    > such as this are not related to the draft. This draft is about evaluating
    > congestion control algorithms for their effect on video quality and frame rates.
    > 
    > So what is my nit with this?  Why does the Security Considerations section
    > contains what it does?
    > 
    >   It is important to evaluate RTP-based congestion control schemes
    >   using realistic traffic patterns, so as to ensure stable operations
    >   of the network.  Therefore, it is RECOMMENDED that candidate RTP-
    >   based congestion control algorithms be tested using the video traffic
    >   models presented in this draft before wide deployment over the
    >   Internet.
    > 
    > This is interesting, but I don't think it has much to do with security. IMO it
    > would be enough to say that this document introduces models for evaluation and
    > doesn't have any security implications.  The existing text should go somewhere
    > else.
    
    To my mind, the security implication is that the algorithm be tested to demonstrate that it doesn’t cause denial-of-service when operating with realistic traffic. This could be, as you note above, that it disrupts the video application by forcing the sending rate to zero; but it’s also important to check that it doesn’t send overly quickly and congest the network, so denying service to other flows. 
    
    -- 
    Colin Perkins
    https://csperkins.org/