Dear Stig, I would like to expand the section of "Security considerations" to the following text: A misbehaving node from within the SFC-enabled domain may alter the content of the Context Headers, which may lead to service disruption. Such an attack is not unique to the Context Headers defined in this document. Measures discussed in Section 8 of [RFC8300] describes the general security considerations for protecting NSH. [I-D.ietf-sfc-nsh-integrity] specifies methods of protecting the integrity of the NSH metadata. If the NSH includes the MAC Context Header, the authentication of the packet MUST be verified before using any data. If the verification fails, the receiver MUST stop processing the variable length context headers and notify an operator. Please review if this could resolve your comments. Thanks! Best Regards, Yuehua Wei M: +86 13851460269 E: wei.yuehua@xxxxxxxxxx ------------------原始邮件------------------ 发件人：StigVenaasviaDatatracker 收件人：rtg-dir@xxxxxxxx; 抄送人：last-call@xxxxxxxx;draft-ietf-sfc-nsh-tlv.all@xxxxxxxx;sfc@xxxxxxxx; 日 期 ：2021年09月30日 08:16 主 题 ：[sfc] Rtgdir last call review of draft-ietf-sfc-nsh-tlv-08 Reviewer: Stig Venaas Review result: Has Issues Summary: The document is easy to read and in a good shape. I have some minor concerns about this document that I think should be resolved before publication. Comments: The document is quite good and easy to read. My only concern is the security considerations that are rather brief. Major Issues: No major issues found. Minor Issues: The Security considerations might need more details. Are there any concerns about incorrect metadata? What are the consequences of metadata being wrong intentionally, or by accident. When should integrity protection be used? _______________________________________________ sfc mailing list sfc@xxxxxxxx https://www.ietf.org/mailman/listinfo/sfc -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
