IS-IS Autoconfiguration
draft-ietf-isis-auto-conf-05

Thanks for this.

I am agreeing with Alvaro's comments.

Thank you for addressing the point raised in the Gen-ART review.

I have a series of comments -- they don't add up to a DISCUSS, but I think it is important that they are solved before publication.

(1) In Section 3.3. (Router-Fingerprint TLV), the format presented doesn't actually show the "flags field", which is described in the text, but it shows its contents.   The length is defined as "the length of the value field", but the figure doesn't explicitly show the Value field.  It is probably obvious that the flags field + Router Fingerprint = Value, but it would be nice to be specific.

Suggestion: include the 1 octet "flags field" in the drawing -- if needed, then show the detail (where the S and A bits are) in the description of the field.


(2) What about the other bits in the Flag field, how should they be registered in the future (if needed)?  Please ask IANA to define a registry for them.

(3) Section 3.1. (IS-IS Default Configuration) mentions several TLVs that MUST NOT be used...and Section 3.3. (Router-Fingerprint TLV) says that this TLV MUST NOT be included in an LSP with a non-zero LSP number.  What should a receiving node do if any of those conditions are not true?

(4) s/3.4.3.  IS-IS System ID Duplication Detection and Resolution/3.4.3.  IS-IS System ID Duplication Detection

(5) I thought the point of this document was for use in "unmanaged deployments.  It allows IS-IS to be used without the need for any configuration by the user."  But Section 3.5. (Additional IS-IS TLVs Usage Guidelines) has recommendations for configuration options, including manually configured adjacencies (which should not be allowed according to Section 3.4.2. (Adjacency Formation)).  Isn't this against the stated reasons for this document?

(6) Authentication is one of those features that could be manually configured -- but the default is no authentication.  There's a higher-than-usual risk of a node listening on the network (probably a bigger problem for the user traffic), but also one that could listen to the Hellos and purposefully trigger the duplicate resolution mechanism to continuously run.  This risk should be highlighted in the Security Considerations because it is newly introduced here. [Robert Sparks pointed this risk out during his GenArt review.]

-4: "In general, the use of authentication is incompatible with auto-
   configuration as it requires some manual configuration."

What are the consequences/risks due to that incompatibility?

Some editorial comments:

page 3:
> It SHOULD not be changed due to device status change (such as
interface > enable/disable, interface plug in/off, device reboot,
firmware update etc.)

The term “due to” is confusing. It might be change to “It SHOULD not
be changed until the device status change”  or “It SHOULD not be
changed as the device status change” according to the meaning.


Page 8 
> As specified in this document, there are two distinguisher need to
be > self-generated, which is System ID and Router-Fingerprint.  

s/which is/which are


Page 9
>  In a network device, normally there are resources which provide an
> extremely high probability of uniqueness thus could be used as seeds
to > derive distinguisher (e.g. hashing or generating pseudo-random
numbers), > such as:

Suggest to split the sentence to make it more readable.

COMMENT
I am having trouble reconciling 3.4.4 and 3.4.6.

3.4.4 seems to tell us how to handle the situation where both System-Id
and Router-Fingerprint are identical:

   If the fingerprints are identical in both content and length (and
   state of the S bit is identical) and the duplication is detected in
   hellos then the both routers MUST generate a new System ID and
   restart the protocol.

And then 3.4.6 says:

   Also note that the conditions for detecting duplicate System
   ID will NOT be satisfied because both the System ID and the Router-
   Fingerprint will be identical.

So, I am confused.


"entropy" is already a collective noun, so I think if you want to
pluralize it, you need to say "sources of entropy"


I am surprised that you are recommending HMAC-MD5, but I guess that's
how IS-IS rolls?

Thanks for your response and updates to the SecDir review.
https://mailarchive.ietf.org/arch/msg/secdir/_DxRs_eINTVE8E-N3S31Zr_10B8

I don't see any privacy considerations with the identifiers created, discussed in System ID and Router-Fingerprint Generation Considerations and Section 3.2.  Are they in later documents that use these identifiers?  I see they may not be unique in home networks, but are there considerations for how they might be used that need to be documented?  Thanks in advance.

Small comment:

section 3.4.2.: "Routers operating in auto-configuration mode MUST NOT form
   adjacencies with routers which are NOT operating in auto-configuration mode."

It's not fully clear to me which actions will follow in this case... abort start-up/configuration and log an error?

* Section 3.3.

The TLV format seems to be off. Why does there seem to be a two octet gap between the Type and Length fields and the Flags field. I think the flag field needs to be pulled forward to bit 16 and the Router fingerprint to bit 24. 

Also agree with Alvaro's comments.