Re: [Lsr] [Tsv-art] Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 06 December 2018 05:08 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54519131025; Wed, 5 Dec 2018 21:08:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.959
X-Spam-Level:
X-Spam-Status: No, score=-15.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4MFFYVwSh69; Wed, 5 Dec 2018 21:08:37 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8DE2130DCF; Wed, 5 Dec 2018 21:08:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17048; q=dns/txt; s=iport; t=1544072916; x=1545282516; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Fb5Moez0Hj3cXIvWJzPfhl2q6rA4EVpL/TdBC8DFH/E=; b=EeFXqljJRP0/EYc2vzT2MEmWtYmlRxNtIppHX+KTDUOxHN657cAXU1Zp a25ACdUkxzY3L0J0S4Or1tUki5Vim1VUp07DGIxgI5PMQrX4Pp7bnWsXJ 1RZ0dTmBNIQFOz52JY+MuRCVVzGk4xacDZKRqPYCTCgrFyEJNX/qwRm2G 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAACcrghc/5tdJa1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ12ZoECJwqDcIgZjA2CDYkSiGWFVoF6CwEBJYRHAheCeiI0CQ0BAwEBAgEBAm0cDIU8AQEBBCMKTBACAQgRBAEBKAMCAgIfERQJCAIEDgUIgxqBHUwDFQ+lXIEviAYNghcFiVaCSBeBQD+DdS6CV0cBAQIBghSCToJXAokQEoIBg3uGTYpALgkChwGHEYMmIJEwjXWBDYlZAhEUgScfOIFVcBU7gmyLHIU/QTGKRIEfAQE
X-IronPort-AV: E=Sophos;i="5.56,321,1539648000"; d="scan'208,217";a="492172632"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Dec 2018 05:08:29 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id wB658TNe012350 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 6 Dec 2018 05:08:29 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 5 Dec 2018 23:08:28 -0600
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1395.000; Wed, 5 Dec 2018 23:08:28 -0600
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
CC: "nishida@wide.ad.jp" <nishida@wide.ad.jp>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "lsr@ietf.org" <lsr@ietf.org>, IETF list <ietf@ietf.org>, "draft-ietf-lsr-isis-rfc7810bis.all@ietf.org" <draft-ietf-lsr-isis-rfc7810bis.all@ietf.org>
Thread-Topic: [Tsv-art] Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03
Thread-Index: AQHUjM5a8eQq42aaJEev+sbr2yTKKqVw2iZAgACLDAD//8LlYA==
Date: Thu, 06 Dec 2018 05:08:28 +0000
Message-ID: <779408ffacd34d75ad438590cb0e0c33@XCH-ALN-001.cisco.com>
References: <154403709395.31955.8914260506541556177@ietfa.amsl.com> <347556ed4ea34fa7844085e5a6639f13@XCH-ALN-001.cisco.com> <CAKKJt-eCZWF=BSxuW85wwzMQBLk=eULw_asHOv7HLetK8oiBzg@mail.gmail.com>
In-Reply-To: <CAKKJt-eCZWF=BSxuW85wwzMQBLk=eULw_asHOv7HLetK8oiBzg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.92.2]
Content-Type: multipart/alternative; boundary="_000_779408ffacd34d75ad438590cb0e0c33XCHALN001ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/Q2SpZ0T-4Q9hH3YaEqTwaXCYhK4>
Subject: Re: [Lsr] [Tsv-art] Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Dec 2018 05:08:43 -0000

Spencer –

The choice of whether to use cryptographic authentication or not is a deployment decision. It is not the place of this RFC (or any other IGP RFC) to require that a customer use authentication of any kind. However, in Security sections we do mention that the use of cryptographic authentication may well be prudent to avoid risks associated with the advertisements which the document is defining.

Make sense?

I agree there is an editorial issue.

“mitigation the risk” should be “mitigation of the risk”

I will address that.

   Les


From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Sent: Wednesday, December 05, 2018 6:41 PM
To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
Cc: nishida@wide.ad.jp; tsv-art@ietf.org; lsr@ietf.org; IETF list <ietf@ietf.org>; draft-ietf-lsr-isis-rfc7810bis.all@ietf.org
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-lsr-isis-rfc7810bis-03

Hi, Les,

On Wed, Dec 5, 2018 at 6:52 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com<mailto:ginsberg@cisco.com>> wrote:
Yoshi -

Thanx for taking the time to review.

I can appreciate that this may the first time you have looked at RFC7810 - let alone the bis draft. As a result you have commented on content which is common to the bis draft and the RFC it is modifying (RFC 7810).

While your questions in isolation may be interesting, I believe they are out of scope for the review of the bis draft. What the bis draft is doing is addressing two modest errata - details of which can be found in https://tools.ietf.org/html/draft-ietf-lsr-isis-rfc7810bis-03#appendix-A
Comments on content not related to those changes is out of scope.

If you have an interest in this topic and want to comment on the substance of RFC 7810 and its companion document for OSPF RFC 7471, I encourage you to do so. Note that all of your comments (save the one on Security) are also applicable to RFC 7471 - so any agreed upon modification would need to be made to both documents. But I do not want to even start discussing such changes in the context of reviewing the bis draft changes. I hope you can understand why.

As regards your Security comment, I am not sure I understand what you are suggesting. As IGP info is flooded hop-by-hop, man-in-the-middle attacks have to be able to insert themselves on an IGP enabled link. Use of cryptographic authentication prevents untrusted sources from being accepted - which is the point being made.

I'm just making sure I understand this last point.

The text Yoshi flagged,

    "The use of Link State PDU cryptographic authentication allows mitigation
    the risk of man-in-
     the-middle attack."

is saying "smart people would use Link State PDU cryptographic authentication unless they have a reason to be OK with man-in-the-middle attacks", but there's no normative requirement to use this mitigation technique.

I think that's what Yoshi was asking about.

Is that the intent?

Thanks,

Spencer

p.s. Is there a missing word after "mitigation"?