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

"Les Ginsberg (ginsberg)" <> Mon, 10 April 2017 21:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D282128D2E; Mon, 10 Apr 2017 14:56:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wy-NoYFATihN; Mon, 10 Apr 2017 14:56:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 01FA0128DF3; Mon, 10 Apr 2017 14:56:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=5928; q=dns/txt; s=iport; t=1491861381; x=1493070981; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=n3XMyq4O4UEhJovT9OXXMa3z9BFNzeClGPaN/RqHAto=; b=XtchhriF7EZIGAslGJXIvg4q/1PNg9RXFzlMqWuwXJ60A0g989b81pDJ PM19F4FaT+VCKqsLbdHGqvncxIX8R+g3jU9p1Pvt+9p11CTyEbVnoJJ7K GAeWoCU1ZPJcEhnVin8tDc0Oq5nablpx1xDnPEqLHSzxK1qSPsN0GkuZg 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.37,183,1488844800"; d="scan'208";a="231311236"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2017 21:56:19 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v3ALuJbM010711 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 10 Apr 2017 21:56:19 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Apr 2017 16:56:18 -0500
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Mon, 10 Apr 2017 16:56:18 -0500
From: "Les Ginsberg (ginsberg)" <>
To: Eric Rescorla <>, The IESG <>
CC: "" <>, Hannes Gredler <>, "" <>, "" <>, "" <>
Thread-Topic: Eric Rescorla's No Objection on draft-ietf-isis-auto-conf-04: (with COMMENT)
Thread-Index: AQHSsj2R7mDoblC0lkSAG0ZsoTpOL6G/Hv3w
Date: Mon, 10 Apr 2017 21:56:18 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Isis-wg] Eric Rescorla's No Objection on draft-ietf-isis-auto-conf-04: (with COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Apr 2017 21:56:24 -0000

Eric -

Thanx for the review.

> -----Original Message-----
> From: Eric Rescorla []
> Sent: Monday, April 10, 2017 2:01 PM
> To: The IESG
> Cc:; Hannes Gredler;;
> Subject: Eric Rescorla's No Objection on draft-ietf-isis-auto-conf-04: (with
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.


> "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 "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.