I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. Sorry this is a bit late.
The summary of the review is Ready with Issues.
This Standards Track draft on "Locator/ID Separation Protocol (LISP) Map-Versioning" obsoles the previous Experimental RFC 6834. I have not been following LISP but I read draft-ietf-list-introduction before reviewing this draft so I think I understand what's going on.
SECURITY
This draft appears to completely ignore the issue of Map Version Number advancing so far so quickly that an old version number is encountered that appears to be newer than or equal to the current version number. Why can't this happen? Or if it can, why doesn't that hurt?
Section 8, last paragraph: Says Map-Versioning can only be used in trusted, closed environments but Section 7.1 and 7.2 seem to talk about what to do about the Map-Version field without any reference to this, but mentioning private deployments for certain error conditions. For example, Section 7.2 point 3 says to discard a packet on an erroneous Map-Version value except perhaps in some private deployments. But if you MUST NOT use Map-Versioning on the open internet, shouldn't it be required to discard all LISP encapsulated packets with Map-Version numbering if received over the public Internet?
Otherwise, the Security Considerations seem adequate although I think the 1st and 2nd paragraphs of Section 8 should be swapped.
OTHER ISSUES
Section 6, right after equation 3: Isn't "(69 + 4096) mod 4096" the same as "69"? And isn't 69 equal to 69, not less than 69? Shouldn't it say "Map-Version numbers in the range [69 + 2049; 68] are smaller than 69"? Or actually "in the ranges [69 + 2049; 4095] and [1;68] are smaller than 69"?
Section A.3: How is it possible to tell that no more traffic will be received? Should this instead be something like wait the TTL of the mappings to that RLOC plus estimated transit time and some margin for safety?
TYPOS/MINOR
Should the document say anything about mapping changes possibly causing re-ordering?
Section 1: I think the following should end with "ITR": "If this is not the case, the ETR can directly send a Map-Request containing the updated mapping to the ETR,"
Section 7.2, first sentence after point 3: Suggest using "MAY" in "may be more restrictive."
Section A.2.3: "provider edge" pops up here with no other mention or explanation anywhere in the draft
Section A.2.3: The last two sentences sound like they contradict each other. I assume the last sentence is refering to change in the Source mapping. Suggest "the mapping" -> "the Source mapping".
EDITORIAL
Section 1: "This operation is two-fold." -> "This information has two uses."
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
The summary of the review is Ready with Issues.
This Standards Track draft on "Locator/ID Separation Protocol (LISP) Map-Versioning" obsoles the previous Experimental RFC 6834. I have not been following LISP but I read draft-ietf-list-introduction before reviewing this draft so I think I understand what's going on.
SECURITY
This draft appears to completely ignore the issue of Map Version Number advancing so far so quickly that an old version number is encountered that appears to be newer than or equal to the current version number. Why can't this happen? Or if it can, why doesn't that hurt?
Section 8, last paragraph: Says Map-Versioning can only be used in trusted, closed environments but Section 7.1 and 7.2 seem to talk about what to do about the Map-Version field without any reference to this, but mentioning private deployments for certain error conditions. For example, Section 7.2 point 3 says to discard a packet on an erroneous Map-Version value except perhaps in some private deployments. But if you MUST NOT use Map-Versioning on the open internet, shouldn't it be required to discard all LISP encapsulated packets with Map-Version numbering if received over the public Internet?
Otherwise, the Security Considerations seem adequate although I think the 1st and 2nd paragraphs of Section 8 should be swapped.
OTHER ISSUES
Section 6, right after equation 3: Isn't "(69 + 4096) mod 4096" the same as "69"? And isn't 69 equal to 69, not less than 69? Shouldn't it say "Map-Version numbers in the range [69 + 2049; 68] are smaller than 69"? Or actually "in the ranges [69 + 2049; 4095] and [1;68] are smaller than 69"?
Section A.3: How is it possible to tell that no more traffic will be received? Should this instead be something like wait the TTL of the mappings to that RLOC plus estimated transit time and some margin for safety?
TYPOS/MINOR
Should the document say anything about mapping changes possibly causing re-ordering?
Section 1: I think the following should end with "ITR": "If this is not the case, the ETR can directly send a Map-Request containing the updated mapping to the ETR,"
Section 7.2, first sentence after point 3: Suggest using "MAY" in "may be more restrictive."
Section A.2.3: "provider edge" pops up here with no other mention or explanation anywhere in the draft
Section A.2.3: The last two sentences sound like they contradict each other. I assume the last sentence is refering to change in the Source mapping. Suggest "the mapping" -> "the Source mapping".
EDITORIAL
Section 1: "This operation is two-fold." -> "This information has two uses."
Thanks,
Donald
===============================
Donald E. Eastlake 3rd +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
