Last Call Review of draft-ietf-savi-send-10
review-ietf-savi-send-10-secdir-lc-roca-2014-01-09-00
Request | Review of | draft-ietf-savi-send |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2014-01-07 | |
Requested | 2013-12-12 | |
Authors | Marcelo Bagnulo , Alberto Garcia-Martinez | |
I-D last updated | 2014-01-09 | |
Completed reviews |
Genart Last Call review of -10
by Alexey Melnikov
(diff)
Secdir Last Call review of -10 by Vincent Roca (diff) |
|
Assignment | Reviewer | Vincent Roca |
State | Completed | |
Request | Last Call review on draft-ietf-savi-send by Security Area Directorate Assigned | |
Reviewed revision | 10 (document currently at 11) | |
Result | Has issues | |
Completed | 2014-01-09 |
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/