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

[Alvaro Retana <[e-mail]>]

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 ([e-mail]) 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 <[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)
> >
> >
> >