[secdir] secdir review of draft-ietf-savi-fcfs-09.txt

[Juergen Schoenwaelder <[e-mail]>]

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: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>