I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. -- My first question was triggered by text on page 8: [...] Before creating a SAVI binding in the local SAVI database, the SAVI device will send a NSOL message querying for the address involved. Should any host reply to that message with a NADV message, the SAVI device that sent the NSOL will infer that a binding for that address exists in another SAVI device and will not create a local binding for it. Now, that sounded like it is easy to DoS new devices simply by generating fake NADV messages. Later in section 3, it seems you only accept NADV messages from trusted ports. If my reading is correct, then a better wording might be: [...] Before creating a SAVI binding in the local SAVI database, the SAVI device will send a NSOL message querying for the address involved. Should any host _on a trusted port_ reply to that message with a NADV message, the SAVI device that sent the NSOL will infer that a binding for that address exists in another SAVI device and will not create a local binding for it. But then I am not sure whether it is really practical to assume that NADV messages always come from a trusted port. -- My second question concerns the construction of the prefix list. One option is to learn prefixes by listening to Router Advertisements. Is there a way to make SAVI do bad things by announcing bogus prefixes? -- My third question concerns this statement in the security considerations: The other type of attack is when an attacker manages to create state in the SAVI device that will result in blocking the data packets sent by the legitimate owner of the address. In IPv6 these attacks are not an issue thanks to the 2^64 addresses available in each link. The second sentence makes this sound like a non-issue but it seems to be correct only if devices uniformly pick random addresses out of the full 2^64 address space. If for whatever reason I can guess with a decent likelihood an address, it looks like SAVI becomes a tool to help me with denying service for such an address. -- Editorial nits: - p10: s/because the connect/because they connect/ (twice) - p10: s/through validating port/through validating ports/ - p11: s/prefixes.A/prefixes. A/ - p13: s/may due/may be due/ - p13: s/packets has been/packets have been/ - p18: s/relay/rely/ - p24: s/coalition/collision/ - p26: s/case fixed/case of fixed/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 < http://www.jacobs-university.de/ >