Last Call Review of draft-ietf-lisp-ddt-08
review-ietf-lisp-ddt-08-secdir-lc-perlman-2016-10-20-00

Request Review of draft-ietf-lisp-ddt
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-10-17
Requested 2016-10-06
Draft last updated 2016-10-20
Completed reviews Genart Last Call review of -08 by Dale Worley (diff)
Secdir Last Call review of -08 by Radia Perlman (diff)
Opsdir Last Call review of -08 by Linda Dunbar (diff)
Rtgdir Early review of -07 by Ben Niven-Jenkins (diff)
Assignment Reviewer Radia Perlman
State Completed
Review review-ietf-lisp-ddt-08-secdir-lc-perlman-2016-10-20
Reviewed rev. 08 (document currently at 09)
Review result Ready
Review completed: 2016-10-20

Review
review-ietf-lisp-ddt-08-secdir-lc-perlman-2016-10-20

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.

This document describes a hierarchical distributed database that helps a router find a mapping between what LISP calls an "endpoint identifier" and "routing locator".

I have not been following LISP, and am not completely convinced that it solves a problem that can't be solved in other ways, but hierarchical distributed databases do seem like the right solution for lots of problems (like DNS).

I do not recommend trying to dive into LISP starting with this document.  Alia Atlas helpfully pointed me at the document "An architectural Introduction to the Locator/ID Separation Protocol".  It would have been nice if this document referenced it, though it's not an RFC...it's an internet draft.

Anyway, from a security point of view, it seems fine, mostly because it's pretty much copied all the security mechanisms from DNSSEC. I do wonder why a whole separate infrastructure would be necessary, and why this information couldn't simply be in DNS.

Radia