Alvaro Retana has entered the following ballot position for draft-ietf-bess-rfc5549revision-04: No Objection
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-bess-rfc5549revision/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) Security Considerations The use of an IPv6 Next Hop opens up the possibility of diverting the traffic: there is no provision in this draft, or rfc2545, to validate or somehow verify that the address is "correct". IOW, a rogue BGP speaker may use a Next Hop address to redirect the traffic elsewhere. Traffic diversion is a known vulnerability, but I would still like to see something in this document about it. Suggestion (borrowing from draft-ietf-idr-tunnel-encaps)> As [RFC4272] discusses, BGP is vulnerable to traffic diversion attacks. The ability to advertise an IPv6 Next Hop adds a new means by which an attacker could cause traffic to be diverted from its normal path. Such an attack differs from pre-existing vulnerabilities in that traffic could be forwarded to a distant target across an intervening network infrastructure (e.g. an IPv6 core), allowing an attack to potentially succeed more easily, since less infrastructure would have to be subverted. Potential consequences include "hijacking" of traffic or denial of service. (2) ยง4: The Extended Next Hop Encoding capability MAY be dynamically updated through the use of the Dynamic Capability capability and associated mechanisms defined in [I-D.ietf-idr-dynamic-cap]. This text creates a Normative dependence on I-D.ietf-idr-dynamic-cap. However, that document expired more than 8 years ago. Please remove this paragraph. (3) It would be very nice if a section summarizing the changes between this document and rfc5549 was included. (4) rfc5549 was written more than 10 years ago...what qualified then as "current" and "new" doesn't anymore. It would be nice to update some of that language. (5) [nits] s/IPV4/IPv4/g s/allows advertising with [RFC4760] of an MP_REACH_NLRI with/allows advertising the MP_REACH_NLRI attribute [RFC4760] with this content _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
