Re: [Idr] Roman Danyliw's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

Roman Danyliw <rdd@cert.org> Thu, 07 January 2021 22:04 UTC

Return-Path: <rdd@cert.org>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD273A0475; Thu, 7 Jan 2021 14:04:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 pXqQRrfY46mG; Thu, 7 Jan 2021 14:04:03 -0800 (PST)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD5A3A046B; Thu, 7 Jan 2021 14:04:02 -0800 (PST)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 107M40Ya004537; Thu, 7 Jan 2021 17:04:00 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 107M40Ya004537
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1610057040; bh=9phSaS3+OHyRAOPBllMOio1L4JfcSlyaPq97Kv5yLJQ=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=b7P71ZqPLGaRd0YlxTUbGtLE3FosLyVxv1G/Pir+P+Pnk2OUuhjJvcm3a6iQ9AP72 ByK+41BzHJHFS1Ewm24GTBmpZBlT20bnKfMRI/7cOUL5ju+qAM9AwSw2VT2niTM/49 +34TOGK02wMuGkCxN+cR/hDo0opSY0uDDu6Wdfrw=
Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 107M3uG5025279; Thu, 7 Jan 2021 17:03:56 -0500
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 7 Jan 2021 17:03:56 -0500
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Thu, 7 Jan 2021 17:03:56 -0500
From: Roman Danyliw <rdd@cert.org>
To: Alvaro Retana <aretana.ietf@gmail.com>, John Scudder <jgs@juniper.net>
CC: Hares Susan <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>, "idr@ietf. org" <idr@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)
Thread-Index: AQHWyYVk7nFLz4GKFkmTp6NObaGpp6nl2yoA//+uN9CAN5cigP//zjCQ
Date: Thu, 07 Jan 2021 22:03:56 +0000
Message-ID: <8f0054672a2d4e81a66b5e1f57199d4e@cert.org>
References: <160700777482.26979.18432434254166024114@ietfa.amsl.com> <DD341C8B-0702-48E1-8411-F99190C8B07D@juniper.net> <6290214a809c48418e8f6c90eb1cc027@cert.org> <CAMMESsxrjgO93QZdS35c8jBXreC2mPmGjmxEyF_wJ_75SRidzA@mail.gmail.com>
In-Reply-To: <CAMMESsxrjgO93QZdS35c8jBXreC2mPmGjmxEyF_wJ_75SRidzA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.202.186]
Content-Type: multipart/alternative; boundary="_000_8f0054672a2d4e81a66b5e1f57199d4ecertorg_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Arm55--EobcOGWPLnYXf5mS0JIY>
Subject: Re: [Idr] Roman Danyliw's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 22:04:06 -0000

Hi John and Alvaro!

Thanks for the update in -21.  It addressed my feedback.  I’ve cleared my ballot.

Roman

From: Alvaro Retana <aretana.ietf@gmail.com>
Sent: Thursday, January 7, 2021 3:01 PM
To: John Scudder <jgs@juniper.net>; Roman Danyliw <rdd@cert.org>
Cc: Hares Susan <shares@ndzh.com>; idr-chairs@ietf.org; The IESG <iesg@ietf.org>; draft-ietf-idr-tunnel-encaps@ietf.org; idr@ietf. org <idr@ietf.org>
Subject: RE: Roman Danyliw's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

Roman:

Hi!  Happy New Year!

John just submitted -21 which should address your concerns.  Can you please take a look?

Thanks!

Alvaro.


On December 3, 2020 at 11:09:28 AM, Roman Danyliw (rdd@cert.org<mailto:rdd@cert.org>) wrote:
Hi John!

Yes, IMO, making it MUST, doesn't require new text. Saying SHOULD means there is additional behavior to cover with mitigation guidance.

I leave it to the WG to determine the right approach. Personally, I agree with your intuition, if someone wants to extend this work they can update it more formally to relax the constraints.

Roman

> -----Original Message-----
> From: John Scudder <jgs@juniper.net<mailto:jgs@juniper.net>>
> Sent: Thursday, December 3, 2020 10:59 AM
> To: Roman Danyliw <rdd@cert.org<mailto:rdd@cert.org>>
> Cc: The IESG <iesg@ietf.org<mailto:iesg@ietf.org>>; draft-ietf-idr-tunnel-encaps@ietf.org<mailto:draft-ietf-idr-tunnel-encaps@ietf.org>; idr-
> chairs@ietf.org<mailto:chairs@ietf.org>; idr@ietf. org <idr@ietf.org<mailto:idr@ietf.org>>; Alvaro Retana
> <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>>; Hares Susan <shares@ndzh.com<mailto:shares@ndzh.com>>
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-idr-tunnel-encaps-20: (with
> DISCUSS and COMMENT)
>
> Would dialing the SHOULD up to a MUST be sufficient to address your concern?
> My previous comment notwithstanding, it occurs to me that if someone does
> want to perform an Internet-wide experiment such as I was speaking of, they
> could write a spec that updates ours, that relaxes the MUST and provides the
> necessary additional security analysis.
>
> —John
>
> > On Dec 3, 2020, at 10:02 AM, Roman Danyliw via Datatracker
> <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
> >
> > [External Email. Be cautious of content]
> >
> >
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-idr-tunnel-encaps-20: Discuss
> >
> > 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discus<https://urldefense.com/v3/__https:/www.ietf.org/iesg/statement/discus>
> > s-criteria.html__;!!NEt6yMaO-
> gk!UgyOh1apt3GeZZrjSh_rt0RuCTnVgC56GutlFG
> > 4vPhwJoDDhz3rRloP77frNgw$ for more information about IESG DISCUSS and
> > COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-iet>
> > f-idr-tunnel-encaps/__;!!NEt6yMaO-
> gk!UgyOh1apt3GeZZrjSh_rt0RuCTnVgC56G
> > utlFG4vPhwJoDDhz3rRloOT5jjipA$
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Per the conversation on my original COMMENT (thanks for the quick
> > response),
> >
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/hV2t6-<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/hV2t6->
> 8mq2dOvmXO-PvLuiON5o4/__;!!NEt6yMaO-
> gk!UgyOh1apt3GeZZrjSh_rt0RuCTnVgC56GutlFG4vPhwJoDDhz3rRloOmECod2w
> $ , I'm escalating this item to a DISCUSS.
> >
> > Section 11
> > However, it is intended that the Tunnel Encapsulation attribute be
> > used only within a well-defined scope, e.g., within a set of
> > Autonomous Systems that belong to a single administrative entity.
> >
> > As this applicability text should be read as a normative SHOULD,
> > please provide a discussion on the risks of open Internet usage in the Security
> Considerations.
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Thank you to Scott Kelly for performing the SECDIR review.
> >
> > ** Section 1.5. Per “Because RFC 8365 depends on RFC 5640, it is
> > similarly obsoleted.”, this seems inconsistent with the meta-data
> > header in the document (as RFC8365 isn’t obsoleted).
> >
> > ** (original COMMENT, see DISCUSS above) Section 11. Please use
> > normative language on the applicability text restricting use to a
> > single administrative domain.
> >
> > OLD
> > However, it is intended that the Tunnel Encapsulation
> > attribute be used only within a well-defined scope, e.g., within a
> > set of Autonomous Systems that belong to a single administrative
> > entity.
> >
> > NEW (or something like this)
> >
> > However, the Tunnel Encapsulation attribute MUST only be used within a
> > well-defined scope such as a set of Autonomous Systems that belong to
> > a single administrative entity.
> >
> > ** Section 12. Typo. s/tunnelling/tunneling/
> >
> > ** Section 15. Clarifying text
> > OLD
> > "hijacking" of traffic (insertion of
> > an undesired node in the path)
> >
> > NEW
> > "hijacking" of traffic (insertion of an undesired node in the path
> > allowing for inspection or modification of traffic, or avoidance of
> > security controls)
> >
> >
> >