[secdir] Secdir review of draft-ietf-savi-send-10

[Vincent Roca <[e-mail]>]

Hello,

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.

IMHO, the document is Almost ready.


This i-d contains a detailed Security Consideration sections which is great.
However I have a few questions and comments.

1/ Section 5 says:
   "The interaction in a mixed scenario comprising SEND and non-SEND
   devices should be addressed in other document."
What happens if an attacker behaves as a non-SEND host? Is it sufficient
to escape SEND SAVI and launch an attack? This is not said.


2/ Section 5.2 says:
   "The recommended minimum
   is the memory needed to store 4 bindings associated to the port."
If there are several hosts behind this port (e.g., several hosts behind a hub
attached to this switch, or several virtual machines), this value of 4 may not
be sufficient. I agree that having per-port buffers is fine, but specifying a
value is risky.


3/ Section 5.2 is a bit confusing and I'm wondering if it could not be simplified.
Basically, it says:
- in case of memory shortage, it is RECOMMENDED to "delete the entries with
  a higher Creation time".
  BTW, what do you mean by "higher creation time"? The oldest entries?
- it is RECOMMENDED to reserve some memory for each port in order to isolate
  the effects to the attacker's port;
- one MUST limit the maximum amount of memory used to store data packets
  in order to keep memory for other tasks;
- one SHOULD rate limit packets which may trigger SEND SAVI events, since
  it requires costly crypto operations.
  BTW, why do you say "which may trigger" instead of "which trigger"?

Third paragraph is strange. I read:
   "As the SEND SAVI device may store data packets while the address is
   being verified..."
If the incoming packet rate is higher than the packet verification rate, sure
there will be problems. Is it what the authors mean? I don't see any good
solution except rate limiting the incoming packet flow.

Later:
   "The effects of such attacks may be limited to
   the lack of capacity to store new data packets."
	Does it mean that setting an upper limit to the amount of memory devoted
to store data packets is a way to mitigate the attack (last sentence),
or does it mean that the attack will lead packets to be dropped (following
sentence)?

And when it is said that:
   "A SEND SAVI device MUST limit the amount of
   memory used to store data packets, allowing the other functions to
   have available memory even in the case of an attacks..."
What do you mean by "other functions"? SEND SAVI functions? Others?


5/ Section 5.4 says that "a SEND SAVI MUST NOT log binding anchor information
except [if there's a good reason for that]". And later that "information about
the majority of hosts that never spoof SHOULD NOT be logged."

The intention is fine, but if I understand correctly, SAVI requires to identify
a host's legitimate IP source addresses (RFC 7039). It means that this information
will be logged any away as SAVI needs it (if I understand correctly).
Or may be by "logging" you mean "long term logging" but in that case this is
not clear. Or is there something else I've missed?


Typos:

** s/reply/replay  in:
   "There are two different cases to analyze when considering SEND SAVI
   reply attacks:"

** s/In this two cases/In these two cases/

** s/messages which does not result in changes/messages which do not result in changes/

** s/in the case of an attacks such those described above/in the case of an attack like the one described above/