Last Call Review of draft-ietf-lisp-rfc6830bis-15
review-ietf-lisp-rfc6830bis-15-tsvart-lc-trammell-2018-08-27-00
| Request | Review of | draft-ietf-lisp-rfc6830bis |
|---|---|---|
| Requested rev. | no specific revision (document currently at 32) | |
| 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 32) | |
| Review result | Ready with Issues | |
| Review completed: | 2018-08-27 |
Review
review-ietf-lisp-rfc6830bis-15-tsvart-lc-trammell-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.