Reviewer: Vincent Roca
Review result: Not Ready
Hello,
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.
Summary: not ready
I am new to LISP and reviewing this ID is also an opportunity to have a new
fresh look at it. In practice, I got stuck on the "Overview" (section 3) and
could not go any further, too many open questions.
My comments:
-- Section 3 "Overview": I was expecting an overview of the ID, its goals, key
principles, some technical aspects but not too much (it's an overview). The
first two high level paragraphs provide some insights but do not achieve the
above objectives. And the following are technical details not easy to read.
Even if I'm not necessarily the target reader, an overview should be
understandable for someone knowledgeable in security.
-- using a single list of 1. to 6. items that mixes several notions complicates
the understanding. I suggest splitting into 2 distinct parts: Registration (1.
to 4.), then Request (5. and 6.). Also item 2. is badly placed (see below).
-- Item 1.
I don't understand the distinction here between entity vs. client (these terms
are not defined in section 2). What is meant by "A 3rd party entity that
provides a service": what service? What relationship with the EID? Why 3rd
party? Is the "client" of this item the same "client" as in paragraph 2
("client of the mapping system")?
-- I don't understand Item 2.
It's a bit contradictory, since it starts with "Anyone can lookup" and later it
explains that there's a "group level auth". If there's a group access control,
do not say anyone can lookup, it's not the case. I also do not understand why
this item 2. is here rather than later, in the "Request" part.
-- Item 3., why are non-Crypto-EID mentioned?
If I understand, this ID is proposing the Crypto-EID (Intro says: "In this
proposal the EID is derived from a public key"). So why should the ID give so
much importance to the non-Crypto-EID? If it's similar, it's sufficient to say
so rather than duplicating the description as if it was a new mechanism. Also
is "any EID type" equivalent to "non-Crypto-EID"? Choose the right terminology
and stick to it throughout the ID.
-- Item 4., first sentence says: "from the **registered** Crypto-EID".
This item describe the processing of a registration request, whereas it refers
to an **already registered** Crypto-EID. If you mean: "the Crypto-EID contained
in the Map-Request message", say so. Also, the whole description of the
verification process is unclear to me.
-- I think Section 3 could benefit from a high level figure, that shows the
actors, which one sends registrations or requests, where the mapping DB is,
what it contains, plus key info in the registration and requests messages, etc.
-- Section 3, 1st paragraph:
Last sentence of 1st paragraph gives the objectives of the ID: "providing a
more granular level of authentication as well as a simpler way to manage keys
and password". That's fine, but after reading items 1. to 6. I don't understand
how this is achieved, how "granular and simple" it is, and to what it needs to
be compared to assess these benefits. Please give just a little bit more
context.
-- Abstract says that "no new PKI infra" is required, and Section 3, paragraph
2, says that the "clients of the mapping system" are authenticated using Public
Key crypto. Perfect, but if there is no PKI, how can LISP prevent any entity to
pretend to be an official client of the mapping system, a Pub/Priv key pair is
not sufficient alone. Items 1. to 6. do not answer and something is missing.
Please clarify the claim.
I'll wait for your updated ID before reading the rest of the ID.
And sorry for the delay.
Regards, Vincent
_______________________________________________
lisp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
