Hi Ben,
Thanks for the quick review. Please find my comments inline.
Summary:
This draft is almost ready for publication as an RFC. (The
draft does
not identify the intended status--I assume it to be standards
track).
I have some questions that should be addressed first, as well
as some
minor editorial comments.
Comments:
Substantive:
-- The draft does not state its intended status.
Will fix this. It's a standards track.
-- The draft suggests that this extension can be used for arbitrary
cryptographic authentication mechanisms, and defines how it is used
for HMAC-SHA. However, I found no text on how to extend it for other
mechanisms.
We have some text with effect to this in Sec 2. It is a well known
mechanism to use the Key IDs to identify the keys used at the two ends.
The receiving router needs to do a local lookup against the key ID to
determine which authentication algorithm, the secret key, needs to be
used for the incoming packet. The assumption was that any reader
proficient enough to understand (or implement) this document would be
aware of how the Key IDs are used.
For example, is the hash algorithm list intended to be
extensible? Should there be an IANA table for that, then? Are the
There is no need for this as the Key ID gives all this information.
parameters in this new authentication type assumed to be sufficient
for any arbitrary mechanism?
Yes. Assume that a new authentication algorithm is invented in future
which takes some "n" additional parameters for its operation. We don't
need to specify these parameters in our PDU. All we need to do is to
have a Key ID which maps to an SA, which in turn stores those additional
parameters. All one needs to ensure is that the two ends have the same
view of that Key ID. Using a Key ID is not new in IETF and the details
of how these are established is beyond the scope of this document.
-- Section 2, first bullet point:
Can you provide motivation for a single octet length for Key ID? I'm
not saying this is wrong; just that it would be good to know
that this
is a considered choice rather than an arbitrary one. My
instinct is to
wonder if limiting the Key-ID space to 256 values is too
small. Also,
I agree. I think we should extend this to 4 octets.
it would be good to mention that administrators will need to
keep the
Key-ID assignments consistent between members of an SA.
Sure, this can be done.
-- Section 2, second bullet:
How is the selected algorithm encoded into the 1-octet
Authentication
Algorithm field?
Section 2 details the parameters associated by the ISIS Security
association indexed by the Key ID. One does not need to carry this in
the ISIS PDU. Its, as I mentioned above, derived at the receiving end by
a lookup done against the Key ID.
-- Section 3.5, 2nd to last paragraph:
I suspect this paragraph has significant security
considerations that
should be addressed in section 4.
Sure, will do that.
-- Section 3.5, last paragraph:
This paragraph seems to make a normative statement about
implementations that _don't_ implement this extension. Is that the
intent?
Yes, it was intentional.
Editorial:
-- Section 1, first paragraph: Lots of acronyms here--please
consider
expanding on first use.
Ok, will do that.
-- Section 1, last paragraph: I suggest scoping this statement with
something to the effect of "At the time of this writing, no openly
published..."
Ok.
-- Section 3.2:
I assume the area, link, and domain authenticated strings are
described in the original IS-IS doc? If so, can you reference
them by
section?
Sure.
-- Section 3.3, "K" -- Can you provide a reference for ISO 10589?
Ok.
-- Section 8
The author list here does not match the first page. Should some of
these move to a "Contributors" section?
Will fix this.
Cheers,
Manav
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf