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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Thu, 03 Dec 2020 07:02:54 -0800

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://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-idr-tunnel-encaps/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Per the conversation on my original COMMENT (thanks for the quick response),
https://mailarchive.ietf.org/arch/msg/idr/hV2t6-8mq2dOvmXO-PvLuiON5o4/, 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)

---

From: John Scudder <[email-masked]>
Date: Thu, 3 Dec 2020 15:58:52 +0000

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 <[email-masked]> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Please refer to https://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!UgyOh1apt3GeZZrjSh_rt0RuCTnVgC56GutlFG4vPhwJoDDhz3rRloP77frNgw$
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/__;!!NEt6yMaO-gk!UgyOh1apt3GeZZrjSh_rt0RuCTnVgC56GutlFG4vPhwJoDDhz3rRloOT5jjipA$
> 
> 
> 
> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/hV2t6-8mq2dOvmXO-PvLuiON5o4/__;!!NEt6yMaO-gk!UgyOh1apt3GeZZrjSh_rt0RuCTnVgC56GutlFG4vPhwJoDDhz3rRloOmECod2w$ , I'm

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 3 Dec 2020 16:09:18 +0000

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 <[email-masked]>
> Sent: Thursday, December 3, 2020 10:59 AM
> To: Roman Danyliw <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; idr-
> [email-masked]; idr@ietf. org <[email-masked]>; Alvaro Retana
> <[email-masked]>; Hares Susan <[email-masked]>
> 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
> 
> > 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
> > s-criteria.html__;!!NEt6yMaO-
> gk!UgyOh1apt3GeZZrjSh_rt0RuCTnVgC56GutlFG
> > 4vPhwJoDDhz3rRloP77frNgw$ for more information about IESG DISCUSS and
> > COMMENT positions.
> >
> >
> > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-iet
> > f-idr-tunnel-encaps/__;!!NEt6yMaO-
> gk!UgyOh1apt3GeZZrjSh_rt0RuCTnVgC56G
> > utlFG4vPhwJoDDhz3rRloOT5jjipA$
> >
> >
> >
> 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.
> >
> >
> > ** 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
> > well-defined scope such as a set of Autonomous Systems that belong to
> > a single administrative entity.
> >
> > "hijacking" of traffic (insertion of an undesired node in the path
> > allowing for inspection or modification of traffic, or avoidance of
> > security controls)
> >
> >
> >