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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 06 December 2018 02:41 UTC

Return-Path: <spencerdawkins.ietf@gmail.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 2054F130F59; Wed, 5 Dec 2018 18:41:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 NuBW8DpMHlOm; Wed, 5 Dec 2018 18:41:14 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33629130F67; Wed, 5 Dec 2018 18:41:11 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id i26so16318170lfc.0; Wed, 05 Dec 2018 18:41:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=J3zLQH/7XpVbbfMrpYyk59wvThfya0ANkC3w5J6S7C4=; b=ZtM5vlXNxNFPSAihcI9LlxJM87kNxV78vF+/uGld6y+QcKdzpRN3MwqwA4/z4aMM5Q A+XCgQvRAzvBQXGqxhNVCsNAwgJosLy0sE6jyIElTQUA2v+YXxzCzH/hoD3KzzIizi1c beDaCakr5Dt+znuABh8pzsCaEzY8exlCcMBiSmy29qDf+AEh3ewb1pud0k1RT1MjwXWV nwFtE3afPdSLcJqxRQ2Mq08HHoURibTecw/dWhcKiKd3T8cq9g5ZP1E26bJ83mtPmmEW qFFWAgR8pQk6Yj3/Eki+zqS510uUqNok8gQG13zxjxWMbcEFb3sLc4mdLV7067ItNsGH TMsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=J3zLQH/7XpVbbfMrpYyk59wvThfya0ANkC3w5J6S7C4=; b=WNwudhPvNFqRj4phwEYzACvtEv7U8Nv0yxD86LqvnGJTNW7gBnx9gTUoYcAhvtfmLu ODbkj4vaCHQtA6jctCiIkogr4bgiBprH5TtDPdwr4IleEWLPmCO2+fvQY+jOfknFAi76 sI1zdYTjHfzMbtRqNulmwaAmcFoLy7kDOcrC0HAfFDDjhXuTa+aSmD8fCjRtUgvCyeL6 3fiEO6zx7c0hNhbQAHfyXmRPZy4PzM2PA+QuYuWMnhHbytkgA7ZAwprjXPTmow1cyHhd AvzXmblDflfC9SfWR+pr0sDkzH3LwFhc+hVSZ9hFHeeFSZKAfabksuPqM7y2zy/q1jAv 0iuA==
X-Gm-Message-State: AA+aEWbG6KdagB6fBSLVyIMCNtQuf3JbnuMC6332jDR9ouThDYjgF2tB 2IJnFA1+UJnqdTnLCDoi/h/9D+JQPteOmuRw50swFefB
X-Google-Smtp-Source: AFSGD/WBC/X2GJedK57M9MG90u+7gnKn1jNNqfcyEZpeEYbMBWKT56rNlNQL/8bqlikxirQWgFxCXG02XXmtGOZYuYw=
X-Received: by 2002:a19:c115:: with SMTP id r21mr15542022lff.144.1544064069253; Wed, 05 Dec 2018 18:41:09 -0800 (PST)
MIME-Version: 1.0
References: <154403709395.31955.8914260506541556177@ietfa.amsl.com> <347556ed4ea34fa7844085e5a6639f13@XCH-ALN-001.cisco.com>
In-Reply-To: <347556ed4ea34fa7844085e5a6639f13@XCH-ALN-001.cisco.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 05 Dec 2018 20:40:56 -0600
Message-ID: <CAKKJt-eCZWF=BSxuW85wwzMQBLk=eULw_asHOv7HLetK8oiBzg@mail.gmail.com>
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
Content-Type: multipart/alternative; boundary="0000000000005bc023057c516e30"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/x81kDM-uLwSarDVrHei99-74yXU>
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 02:41:19 -0000

Hi, Les,

On Wed, Dec 5, 2018 at 6:52 PM Les Ginsberg (ginsberg) <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"?