[secdir] Secdir review of draft-ietf-lisp-introduction-10

Radia Perlman <radiaperlman@gmail.com> Mon, 26 January 2015 19:49 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 9FEFE1AD1BA; Mon, 26 Jan 2015 11:49:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 71wrM5L6AC3L; Mon, 26 Jan 2015 11:49:16 -0800 (PST)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B25B1AD210; Mon, 26 Jan 2015 11:49:14 -0800 (PST)
Received: by mail-lb0-f178.google.com with SMTP id u10so9460135lbd.9; Mon, 26 Jan 2015 11:49:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=iLJMO73M9xG9+GyDHahF8i5wIU+Pk7O4B/kazYABQyk=; b=hVef/kFqBr/U+tS2dCLI2hJeIpIiB1hA1xtY4hinO0rQyH/cPJqOU7bADycqtfcRjw rm6K7NwkxhnSn/Bju2G/16WE5uQnlHWnaBHaUSp2V3wg06sZkKkxoRNX4TjSOLsYlSXB wLn62eWnx5Dxt+bhc0nF4Xa1KnBjZfOtPDYR2r2NWD5WSSTtwf8WA3nJRF/iEYte4p+m ga2c3k5i9uEGCLPH+xhXjKEN6AQ/UFSq64c6hxG/FOYENAPhmTZcQJ/bj/SgOmGaPBUp CXIGBCZ3F70EV8najS7X7KHXTf5dFYk1f6taC+I1If6dFsXrv6BvUem4WrpGoyvAdJ+h zTSA==
MIME-Version: 1.0
X-Received: by with SMTP id oc1mr63235lbb.7.1422301753146; Mon, 26 Jan 2015 11:49:13 -0800 (PST)
Received: by with HTTP; Mon, 26 Jan 2015 11:49:13 -0800 (PST)
Date: Mon, 26 Jan 2015 11:49:13 -0800
Message-ID: <CAFOuuo49UJh4Q5k8AiR4-+=gKg+g2Neg72xXg4wYgGnBkKAgng@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b343318c28147050d936ea3
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/L2mZM3m6JEAsGsJHZN4SM2fCnkw>
Cc: The IESG <iesg@ietf.org>, draft-ietf-list-introduction.all@tools.ietf.org
Subject: [secdir] Secdir review of draft-ietf-lisp-introduction-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jan 2015 19:49:20 -0000

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?


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"