Subject: [Isis-wg] Eric Rescorla's No Objection on draft-ietf-isis-auto-conf-04: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Apr 2017 14:00:56 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-isis-auto-conf-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-isis-auto-conf/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 10 Apr 2017 21:56:18 +0000

Eric -

Thanx for the review.

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
> Sent: Monday, April 10, 2017 2:01 PM
> To: The IESG
> Cc: [email-masked]; Hannes Gredler; [email-masked];
> [email-masked]; [email-masked]
> Subject: Eric Rescorla's No Objection on draft-ietf-isis-auto-conf-04: (with
> COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> 3.4.4 seems to tell us how to handle the situation where both System-Id and
> Router-Fingerprint are identical:
> 
[Les:] This is a bit of a subtle point and is easier to understand if you have some familiarity with the protocol. Let me try to explain.

In 3.4.4, we specifically talk about the case where duplicates are detected in hellos received from our immediate neighbors. In this case we know that there actually are two active systems using the same system-id/fingerprint and so we can immediately initiate the resolution procedures.

In 3.4.6 we are handling the case where the duplication is detected because we have received an LSP which looks like "it is from ourselves". In such a case we have to distinguish between the benign false positive cases and the actual cases. How can a false positive occur?

Suppose a router is running and generates LSP #0 with its system-id/fingerprint. This LSP is flooded network-wide and exists in the databases of all routers in the network. The LSP will be preserved in the databases of all routers for the LSP lifetime (default of 20 minutes).

The router then restarts for some reason (maintenance, crash, power failure). If this occurs within the window of LSP Lifetime then other routers in the network will have stale copies of the LSP sent as part of the router's previous incarnation. They will flood this stale copy back to the restarting router. THis will of course appear to be a duplicate since it has the same system-id/fingerprint. But this is a benign event which will be handled by the restarting router by generating a new copy with an updated sequence #  - this is normal handling for such a case defined in the base protocol standard. In order for this NOT to trigger duplicate-id resolution procedures (which we do not want to happen in this case) we need to employ the additional logic defined in Section 3.4.6. Basically, only if this persists over a period of time can we safely conclude that there is a real duplicate.

HTH

> 
> "entropy" is already a collective noun, so I think if you want to pluralize it, you
> need to say "sources of entropy"
> 
[Les:] According to https://www.merriam-webster.com/dictionary/entropy "entropies" is valid.
??

> I am surprised that you are recommending HMAC-MD5, but I guess that's

[Les:] There also is RFC 5310 which defines SHA support - not as widely deployed. And it involves the use of key identifiers requiring additional configuration. 
The thought here is to allow for authentication but try to minimize the config required if it is used.

   Les