IETF Logo Mail Archive

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

Ben Campbell <ben@nostrum.com> Thu, 14 December 2017 23:23 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BAA1287A5; Thu, 14 Dec 2017 15:23:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Level:
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ev2aZpMgUT8c; Thu, 14 Dec 2017 15:23:28 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C084C12714F; Thu, 14 Dec 2017 15:23:28 -0800 (PST)
Received: from [10.0.1.99] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vBENNQG3048869 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 14 Dec 2017 17:23:27 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.99]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <A21C6DCE-A1CA-4F53-A694-DFD385B1C6C9@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_A3B83966-7EDE-422B-A2F5-4FB0EA0B11DF"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Thu, 14 Dec 2017 17:23:25 -0600
In-Reply-To: <BLUPR0501MB2051B013791B5F9EC3B67DA2AE0A0@BLUPR0501MB2051.namprd05.prod.outlook.com>
Cc: The IESG <iesg@ietf.org>, "ggx@gigix.net" <ggx@gigix.net>, "draft-ietf-intarea-probe@ietf.org" <draft-ietf-intarea-probe@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, "intarea-chairs@ietf.org" <intarea-chairs@ietf.org>
To: Ron Bonica <rbonica@juniper.net>
References: <151322108093.6178.3442590912691561741.idtracker@ietfa.amsl.com> <BLUPR0501MB2051B013791B5F9EC3B67DA2AE0A0@BLUPR0501MB2051.namprd05.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/VBldLwc1GiUuargNb3SYcss753M>
Subject: Re: [Int-area] Ben Campbell's No Objection on draft-ietf-intarea-probe-09: (with COMMENT)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Dec 2017 23:23:31 -0000


> On Dec 14, 2017, at 11:03 AM, Ron Bonica <rbonica@juniper.net> wrote:
> 
> Hi Ben,
> 
> Thanks for the review. Comments inline.....
> 
>                    Ron
> 
>> -----Original Message-----
>> From: Ben Campbell [mailto:ben@nostrum.com]
>> Sent: Wednesday, December 13, 2017 10:11 PM
>> To: The IESG <iesg@ietf.org>
>> Cc: draft-ietf-intarea-probe@ietf.org; Luigi Iannone <ggx@gigix.net>;
>> intarea-chairs@ietf.org; ggx@gigix.net; int-area@ietf.org
>> Subject: Ben Campbell's No Objection on draft-ietf-intarea-probe-09: (with
>> COMMENT)

[…]

> [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.

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.





> 
>                                                                                       Ron
> 
>

v2.23.0 | Report a Bug | By Email