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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Eric -

Thanx for the review.

> -----Original Message-----
> From: Eric Rescorla [mailto:[e-mail]]
> Sent: Monday, April 10, 2017 2:01 PM
> To: The IESG
> Cc: [e-mail]; Hannes Gredler; [e-mail];
> [e-mail]; [e-mail]
> Subject: Eric Rescorla's No Objection on draft-ietf-isis-auto-conf-04: (with
> COMMENT)
> 
> 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.
> 
[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
> how IS-IS rolls?

[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


>