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. The summary of my review is: Ready with issues. The proposed extension mechanism is simple to understand. However, my main concern is regarding the nonce size reduction and implications on LISP. While the threat models (on-path and off-path) do not change with this extension, the probability of some off-path attacks might change. Specifically, the probability of correctly guessing a 16 bit nonce is not negligible. This might make attacks in which an adversary tries to convince an ITR of reachability to an otherwise unreachable ETR more likely. From [1], an ITR that sees the nonce echoed correctly “knows that the path to and from the ETR is up.” Thus, I think some discussion of this is necessary in the security considerations. Beyond that, I have the following minor comments and nits: - UDP checksums seem to be the only mechanism in place that give ITRs and ETRs a means of checking datagram integrity. Of course, this means an on-path adversary can muck with the g-Bit from Section 4.1 so as to prevent use of the GPE mechanism. This is not new with this extension, though a comment on the issue might be useful, e.g., in the security considerations. - It would be helpful to include packet diagrams similar to Figure 2 wherein (1) P and V are set and (2) only P is set. While I don’t find the text misleading or confusing, a figure might help other readers. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |N|L|E|1|I|1|K|K| Source MV | Dest MV | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|L|0|0|I|1|K|K| ... 0 ... | Next Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Instance ID/Locator-Status-Bits | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - In Section 4, where it states, "A LISP-GPE router MUST NOT encapsulate non-IP packets to a non LISP-GPE capable router," I might replace "to a non LIST-GPE capable router" with "when the P-bit is set to 0." [1] https://tools.ietf.org/html/draft-ietf-lisp-rfc6830bis-16#section-10.1