Last Call Review of draft-ietf-savi-send-10
review-ietf-savi-send-10-secdir-lc-roca-2014-01-09-00

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/