Last Call Review of draft-ietf-lisp-rfc6830bis-15
review-ietf-lisp-rfc6830bis-15-tsvart-lc-trammell-2018-08-27-00

From a transport standpoint, this document is basically OK -- I suspect that
there are probably more transport-relevant issues to consider on 6833bis, but I
did not review it. Two issues with the dataplane:

(1) Common advice to all UDP-using encapsulation designers and implementors:
please read RFC8085, especially section 3.1.11. As LISP's dataplane is
basically an application of UDP, I was surprised to see no reference to RFC8085
here. I believe that in the most common case LISP falls into case 1 here, but
implementors of LISP ITRs should at least be made aware of the other cases.

(2) This is not transport-specific. Reading the document, it struck me that the
design of the protocol has a few inherently unsafe features related to the fact
that its wire image is neither confidentiality- nor integrity-protected. I
think that all of the potential DDoS and traffic focusing attacks I could come
up with in the hour I spent reviewing the document are indeed mentioned in the
security considerations section, but as the security considerations section
does not give any practical mitigation for dataplane overload attacks, it seems
to be saying that RLOC addresses shouldn't be Internet-accessible, which as I
understand it is not the point of LISP. I haven't seen a secdir review on this
document yet, but I'd encourage the authors to do everything it asks.

nit: Section 7.1. para 7 should note that the ICMPv6 message sent is called
Packet Too Big, not Unreachable/Frag Needed.