Brian Haberman has entered the following ballot position for draft-ietf-spring-problem-statement-06: 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-spring-problem-statement/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The following is a training review from the Suresh Krishnan (incoming INT AD) * Section 3.4 If the intent is to create a new RH type how will the interoperability or backward compatibility be possible? Specifically because intermediate nodes (that are segment routing hops) that encounter unknown RH types are required to drop the packet and send an ICMPv6 Parameter Problem back. * Security considerations In general this document does not talk anything about the security issues with IPv6 routing headers and how they would be avoided. e.g. The following paper describes an attack. [CanSecWest07] Biondi, P. and A. Ebalard, "IPv6 Routing Header Security", CanSecWest Security Conference 2007, April 2007. http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf I think the security considerations are very light and need to be greatly improved. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- * Section 2 This section talks about the Routing header defined in RFC2460 but does not mention that the RH0 has been deprecated by RFC5095. Potentially worth mentioning draft-ietf-6man-segment-routing-header-00. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring