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

[Roman Danyliw <[e-mail]>]

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 <[e-mail]>
> Sent: Thursday, December 3, 2020 10:59 AM
> To: Roman Danyliw <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; idr-
> [e-mail]; idr@ietf. org <[e-mail]>; Alvaro Retana
> <[e-mail]>; Hares Susan <[e-mail]>
> 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
> <[e-mail]> 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
> > 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
> > 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-
> 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)
> >
> >
> >