Hi WG, I read this thread #4 (about filtering of IPv6 address with regard to the presence of SRH) twice and sorry for the repeat :-( Let me summary my points so far: I support close issue #1, #2, #3, #4.
Thanks, Jingrong 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments may contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Jingrong Xie Sent: Friday, August 18, 2023 11:25 AM To: Joel Halpern <j...@joelhalpern.com>; SPRING WG List <spring@ietf.org> Subject: Re: [spring] Confimring resolution of issue #4 https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ Hi WG, I consider this resolution sufficient to close the issue. It is the same as issue #3 to me, and I think the filtering of IPv6 address (SRv6 LOC part) should not rely on the presence of an SRH. Thanks, Jingrong 本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments may contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Joel Halpern Sent: Tuesday, August 8, 2023 11:00 PM To: SPRING WG List <spring@ietf.org<mailto:spring@ietf.org>> Subject: [spring] Confimring resolution of issue #4 https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-srh-compression/ Issue #4 reads: In some cases it is possible that the SR policy can be expressed purely with C-SIDs without requiring an SRH. In this case, to allow the SR domain to fail closed, some form of filtering based on the LOC part of the SRv6 SID is required as relying purely on the presence of an SRH will not be sufficient. I would also like to note upfront that it is already possible based on RFC8754 to send packets without an SRH (e.g. one segment encapsulated into outer header) but having C-SIDs makes it applicable to a wider set of use cases. The response from the editors reads: Added text in revision -01 (Sec. 12<https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-05#section-12>) indicating that the SRv6 security model (Sec. 5.1 of RFC 8754<https://www.rfc-editor.org/rfc/rfc8754.html#section-5.1>) also applies to the SIDs defined in draft-ietf-spring-srv6-srh-compression. The SRv6 security model uses IP address filtering (SRv6 SID block) and does not rely on the presence of an SRH. Please indicate to the list whether you consider this resolution sufficient to close the issue, or have further concerns that should be addressed. If you have concerns, clarity about them is appreciated. This call is open for two weeks, through August 22.
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
