[secdir] secdir review of draft-ietf-lisp-gpe

[Christopher Wood <[e-mail]>]

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