Gunter Van de Velde has entered the following ballot position for draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-14: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Gunter Van de Velde, RTG AD, comments for draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-14 # The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-spring-dhc-distribute-srv6-locator-dhcp-14.txt Thank you for clearing and resolving most of the open discuss’s. (see: https://mailarchive.ietf.org/arch/msg/spring/OH6glu4n3-PhEXcZDlTLNbHgFRs/) The remaining discuss standing is: “ [DISCUSS#3] in the security section i find no discussion on the risk of having locators or sub-sets of locators leak to hosts? This could pose a serious infrastructure security concern when the CPE is located at customer premise. [Co-authors] We fully acknowledge the value of explicitly highlighting such risks. We will add text in the draft as you suggested. This clarification will be included in the Security Considerations section of the next revision. GV2> Thank you “ I found in the security section the following new textblob: “ As a border node device, the CPE MUST implement appropriate traffic filtering capabilities on both its internal and external interfaces, as required by Section 5.1 of [RFC8754]. “ While the document notes that filtering is required, it doesn’t explain why extending segment routing to the CPE is risky. Traditionally, SR-MPLS networks terminate MPLS at the BRAS, not at the customer’s CPE. Connecting the core segment-routing backbone directly to a CPE can introduce security concerns. Adding a brief discussion of these risks and their implications in the security section will help clarify the need for the recommended filters and safeguards. Gunter Van de Velde, Routing AD _______________________________________________ spring mailing list -- [email protected] To unsubscribe send an email to [email protected]
