Hi Warren, Thank you for reviewing!
Please see some comments in-line and let us know if we still need to add information to the security section. Thx Jorge From: Warren Kumari via Datatracker <[email protected]> Date: Wednesday, September 23, 2020 at 6:17 PM To: The IESG <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Bocci, Matthew (Nokia - GB) <[email protected]>, Bocci, Matthew (Nokia - GB) <[email protected]> Subject: Warren Kumari's Discuss on draft-ietf-bess-evpn-na-flags-06: (with DISCUSS and COMMENT) Warren Kumari has entered the following ballot position for draft-ietf-bess-evpn-na-flags-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-bess-evpn-na-flags/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Be ye not afraid! This DISCUSS should be fairly trivial to address... This allows for more information to be carried with MAC/IP Advertisements. It seems to me that this gives a DoS-style attacker more opportunities to exhaust state on routers - I could sit on a wire and create lots of ARP/ND states (make up new IP and MAC combinations), causing this to be propagated and burning memory / state / etc. This is somewhat discussed in RFC 7432, but the technique in this document seems like it makes this issue somewhat worse - a single sentence in the Security Considerations noting it would satisfy me (as would an explanation that I'm mistaken :-)). -------------------- [jorge] we’re happy to add any other explanations in the security section, however I thought your concern could have been addressed by this existing sentence: “In addition, this document adds pieces of information that impact on the way ARP/ND entries are installed in ARP/ND and/or proxy-ARP/ND tables, and therefore the resolution protocols for IPv4 and IPv6 addresses.” Also, can you please clarify what you mean by this?: “this gives a DoS-style attacker more opportunities to exhaust state on routers - I could sit on a wire and create lots of ARP/ND states (make up new IP and MAC combinations), causing this to be propagated and burning memory / state / etc.” Note that the new flags come in an extended community, which is not part of the route key, hence receiving multiple combinations of flags with the same IP->MAC information will not create new state, but update the existing one. As an example, if a PE receives IP1->MAC1(R=1,I=0) and later IP1->MAC1(R=0,I=1), the PE will not create additional state but will update the entry with the latest information. Let me know if I’m missing your point please, and if so it would be great if you can suggest some text for the security section. -------------------- I also support EK & Rob's DISCUSSes [jorge] we think we addressed their discusses… but obviously they (and you) can let us know if it is not the case. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Other than my DISUCSSes, I found this document to be well written and easy to understand - thank you for writing it... [jorge] thank you for your kind words!
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
