In conjunction with the WG last call on this document, I performed my
own review.
I am confused by the attack remediation in section 5.3. This seems t
say that an ETR should reject any packet whose source RLOC is not valid
for the source EID. This would seem to frequently doubling the packet
drop for initial communication between two sites, which seems
unfortunate. This recommendation is repeated in the first bullet of
section 11. Is this really the WG recommendation?
Also, I have some minor issues.
Section 5.2.2 on EID-to-RLOC Cache overflow is written as if this can
only be caused by control plane attacks, or by a device performing
gleaning. This seems to ignore one other attack vector. It is not a
vector which can inject fake entries, but it can disrupt operation.
Namely, an insider sending packets to a broad range of EIDs. By
assumption, the cache is not big enough to hold the whole mapping table
(otherwise it would not be subject to overflow). It would therefore
seem that this sort of attack could disrupt valid entries and interfere
with proper ITR operation. Shouldn't this be mentioned?
Could / should the caveat about rate limiting queries in section 5.4.1
be moved up in the section, so that the reader realizes early what is
needed?
I am wondering about the tradeoff of including DDT in this document. On
the one hand, DDT is where we likely are going. On the other hand,
including that material will mean that this document gets an RFC Editor
hold until LISP DDT is published. Would it make more sense to defer the
DDT specific section to the DDT document?
Editorial:
The title of section 5.3, "Attacks not leveraging on the LISP
header" seems to have a grammatical error. I think the word "on" is
extraneous. (And similarly for section 5.4)
Yours,
Joel M. Halpern
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
