Last Call Review of draft-ietf-lisp-rfc6830bis-15

Request Review of draft-ietf-lisp-rfc6830bis
Requested rev. no specific revision (document currently at 33)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2018-08-29
Requested 2018-08-15
Authors Dino Farinacci, Vince Fuller, David Meyer, Darrel Lewis, Albert Cabellos-Aparicio
Draft last updated 2018-08-27
Completed reviews Rtgdir Last Call review of -14 by John Drake (diff)
Secdir Last Call review of -15 by Kyle Rose (diff)
Opsdir Last Call review of -16 by Scott Bradner (diff)
Tsvart Last Call review of -15 by Brian Trammell (diff)
Genart Telechat review of -16 by Francis Dupont (diff)
Tsvart Telechat review of -19 by Brian Trammell (diff)
Secdir Telechat review of -18 by Kyle Rose (diff)
Assignment Reviewer Brian Trammell
State Completed
Review review-ietf-lisp-rfc6830bis-15-tsvart-lc-trammell-2018-08-27
Reviewed rev. 15 (document currently at 33)
Review result Ready with Issues
Review completed: 2018-08-27


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.