Last Call Review of draft-ietf-lisp-introduction-10
review-ietf-lisp-introduction-10-secdir-lc-perlman-2015-01-29-00

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.

LISP (Locator/ID Separation Protocol) is a protocol supporting separating

the two functions of IP addresses: node identification and node addressing.

It is important in scenarios (like we have today) where organizations own

many disjoint ranges of the IP address space causing routing tables to be

much bigger than they would have to be if every organization owned a single

contiguous space. It also has potential to allow nodes to keep the same IP

address for purposes of identification even when their address for purposes

of routing changes due to mobility or network reconfiguration. It uses

LISP-capable border routers to encapsulate packets and address them to

LISP-capable border routers on the other side of the "core Internet".

This is an introductory document, where there at least nine other documents

specifying details of components used to implement the needed mechanisms.

There is a security considerations section, which focuses on a class of

denial of service attacks. There are presumably security considerations

sections in the other documents, including one that focuses entirely on

security, so it is not necessary that all security issues be brought up

here. That said, I think that if you were to write an "introduction to

security considerations", there are more important ones than the DoS threat.

in particular, as a routing protocol care must be taken to make sure a bad

actor cannot attract someone else's traffic with mechanisms like those we

are trying to address with BGP security. Much of the routing information is

maintained in a database "like DNS". If it *were* DNS, DNSSEC could be used

to address the integrity issues. If it is home grown, some equivalent

mechanism will be necessary.  Why not use DNS?

Non-Security comments:

I assume this document is intended to introduce LISP, and so would logically

be the first document that someone wanting to learn about LISP would read.

It therefore should point to the other LISP documents for more details but

should not depend on them for the purpose of understanding this one. There

are a number of concepts that I believe one would have to understand in

order to understand LISP and being reading the other documents in the

series. I would expect, therefore, that they would be in this document but I

could not find them. (If my assumption is incorrect, and there is some other

document that should be read before this one, that should be mentioned in

the introduction).

Section 2. Having no terms defined and referring to reader to check any of

nine associated documents is not user friendly. It would be nice if at least

one of the documents defined all the terms that were used in more than one

document so there would be one place to go for definitions not included in

the document being read.

EIDs and RLOCs have the same length, appearing to be either IPv4 or IPv6

addresses or perhaps from some other space. Fundamental to understanding

LISP is understanding whether they reuse the same values or whether they

partition the space into EIDs and RLOCs. This is particularly tricky (and

therefore important) in the case of IPv4 addresses, since that space is very

densely filled and there would not be room to divide it into two spaces both

large enough to accommodate the Internet. Is the expectation that EIDs would

be taken from a reserved range (likely the 10.*.*.* range), in which case

growth of LISP will be severely constrained during its coexistence phase, or

alternately will EIDs use the entire range, in which case it will be

difficult or impossible to make LISP nodes interoperate with non-LISP nodes?

In a related question, section 3.2 says that EIDs will typically be

retrieved from DNS. Is the intent that they be retrieved from A or AAAA

records, or from new record types created for LISP. For a LISP node opening

a connection to a non-LISP node, will its DNS lookup return a different

value than when a non-LISP node is opening a connection to a non-LISP node?

How is that made to happen?

More detailed questions (that should probably be addressed in order to

understand the architecture):

Section 3.2 Page 7 item 3: It says that two locators are returned. Is this

just an example where there also might only be one locator or there might be

10, or is it always two? If an example, is there some maximum number of

addresses (or at least some maximum number likely to be used)?

Section 3.3.1: When the UDP header is created, what is used as the source

port? Does the decapsulating router (ITR) ignore the outer source IP address

and the outer source port, or is there some sort of check done on that

information or state established?

Typos:

Page 9: "An RTR can be thought as a" -> "An RTR can be thought of as a"

Page 21: "informations" -> "information"

Page 25: "are note used" -> "are not used"