Subject: [Int-area] Ben Campbell's No Objection on draft-ietf-intarea-probe-09: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Wed, 13 Dec 2017 19:11:20 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-intarea-probe-09: No Objection

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-intarea-probe/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-1.2: There is at least one lower case MUST. Unless that is intended as
normative, please consider using the boilerplate from RFC8174.

-8, last paragraph: "MUST NOT leak information" seems more like a goal or a
statement of fact than a normative requirement. (I think the 2nd MUST in that
paragraph describes the real normative requirement")

---

From: Ron Bonica <[email-masked]>
Date: Thu, 14 Dec 2017 17:03:54 +0000

Hi Ben,

Thanks for the review. Comments inline.....

                    Ron

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Wednesday, December 13, 2017 10:11 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Luigi Iannone <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> Subject: Ben Campbell's No Objection on draft-ietf-intarea-probe-09: (with
> COMMENT)
> 
> 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.)
> 
> 
   [snip]
[RB ] 
Thanks! This will be fixed in the next version.

> statement of fact than a normative requirement. (I think the 2nd MUST in
> that paragraph describes the real normative requirement")
> 
[RB ] 
I respectfully disagree. If PROBE leaks information between routing instances, we will have created a rather serious security vulnerability. So, this is a standing-on-our-heads-serious requirement.

                                                                                       Ron

---

From: Ben Campbell <[email-masked]>
Date: Thu, 14 Dec 2017 17:23:25 -0600

> On Dec 14, 2017, at 11:03 AM, Ron Bonica <[email-masked]> wrote:
> 
> Hi Ben,
> 

[…]

> I respectfully disagree. If PROBE leaks information between routing instances, we will have created a rather serious security vulnerability. So, this is a standing-on-our-heads-serious requirement.

I agree it’s really important, but it’s still a statement of fact. It’s not normative in the sense that it doesn’t offer instruction to implementers so much as it offers a reason for the _next_ requirement:

"Therefore, when a node receives an ICMP Extended Echo Request and the proxy interface is in a different VPN than the probed interface, the node MUST return an ICMP Extended Echo Reply with error code equal to (2) No Such Interface. “

Isn’t _that_ the real normative requirement?

In any case, this is not a blocking comment, so feel free to ignore it :-)

Thanks!

Ben.

---

From: Ron Bonica <[email-masked]>
Date: Fri, 15 Dec 2017 15:17:29 +0000

Ben,

I am convinced. I will change the first MUST NOT to lower case in version 10.

                                          Ron

> Sent: Thursday, December 14, 2017 6:23 PM
> To: Ron Bonica <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; draft-ietf-intarea-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Ben Campbell's No Objection on draft-ietf-intarea-probe-09:
> (with COMMENT)
> 
> 
> 
> > I respectfully disagree. If PROBE leaks information between routing
> instances, we will have created a rather serious security vulnerability. So, this
> is a standing-on-our-heads-serious requirement.
> 
> I agree it’s really important, but it’s still a statement of fact. It’s not normative
> in the sense that it doesn’t offer instruction to implementers so much as it
> offers a reason for the _next_ requirement:
> 
> "Therefore, when a node receives an ICMP Extended Echo Request and the
> proxy interface is in a different VPN than the probed interface, the node
> MUST return an ICMP Extended Echo Reply with error code equal to (2) No
> Such Interface. “
>