Re: [secdir] Secdir review of draft-ietf-avtcore-monarch-17

[Qin Wu <[e-mail]>]

Hi,Tena:
The security section of monarch draft is consistent with RFC3611 and doesn't conflict with the security section of RFC3611.
The 2nd paragraph in security section of monarch draft,  it talks about sensitive information exposting, which said:
"
   In RTP sessions, a RTP system may use its own SSRC to send its
   monitoring reports towards its next-neighbour RTP system.  Other RTP
   system in the session may have a choice as to whether they forward
   this RTP system's RTCP packets.  This present a security issue since
   the information in the report may be exposed by the other RTP system
   to any malicious node.  Therefore if the information is considered as
   sensitive, the monitoring report should be encrypted.

"
the resolution is to use encryption.
 
In the 6th paragraph in security section of RFC3611, it talks about disadvantage of encryption of
XR block, which said:
"
   Any encryption or filtering of XR report blocks entails a loss of
   monitoring information to third parties.  For example, a network that
   establishes a tunnel to encrypt VoIP Report Blocks denies that
   information to the service providers traversed by the tunnel.  The
   service providers cannot then monitor or respond to the quality of
   the VoIP calls that they carry, potentially creating problems for the
   network's users.  As a default, XR packets should not be encrypted or
   filtered.
"
RFC3611 said, it is at default to set XR packet no encrypted. But it doesn't say encryption is prohibited in any circumstance.

To clear your confusion to this, I like to propose the following change to the 2nd paragraph in security section of monarch draft
OLD TEXT:
"
Therefore if the information is considered as
 sensitive, the monitoring report should be encrypted.
"

NEW TEXT:
"
Therefore if the information is considered as
sensitive, encryption of the monitoring report is recommended.
"
Hope this addresses your comments.

Regards!
-Qin

>To: The IESG <iesg at ietf.org>, "secdir at ietf.org" <secdir at ietf.org>, "draft-ietf-avtcore-monarch at tools.ietf.org" <draft-ietf-avtcore-monarch at tools.ietf.org> 
>Subject: [secdir] Secdir review of draft-ietf-avtcore-monarch-17 
>From: Tina TSOU <Tina.Tsou.Zouting at huawei.com> 

>Hello,

>I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the >security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

>Draft-ietf-avtcore-monarch-17 as a whole provides useful advice. 
>There are a number of editorial nits that will be provided to the authors in a separate E-mail.

>Unfortunately, the Security Considerations section fails to appreciate both the more nuanced view and the contradiction exhibited by the same section of RFC 3611, to which it refers. On the one hand, the >measurements reported in XR blocks could be sensitive and one might wish to provide them with confidentiality. On the other hand, intermediate parties may have legitimate reasons to view the >measurements, so that end-to-end encryption is not always desirable.

>It would be helpful for this document to discuss the trust models that might be encountered in operation, and how confidentiality and authorized usage could co-exist within these models. Of course, it may >be legitimate to conclude that under some circumstances such coexistence may be impossible, and local policy may therefore be either to suppress the measurements or accept the consequences of their >disclosure.

>Tina