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

Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> Wed, 13 December 2017 18:12 UTC

Return-Path: <Kathleen.Moriarty.ietf@gmail.com>
X-Original-To: int-area@ietf.org
Delivered-To: int-area@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A07112704B; Wed, 13 Dec 2017 10:12:59 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
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
X-Test-IDTracker: no
X-IETF-IDTracker: 6.67.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151318877929.30204.3784427299489982417.idtracker@ietfa.amsl.com>
Date: Wed, 13 Dec 2017 10:12:59 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/P7rBBjO4ea-zTCbvUaZl06k5fnA>
Subject: [Int-area] Kathleen Moriarty's No Objection on draft-ietf-intarea-probe-09: (with COMMENT)
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 13 Dec 2017 18:12:59 -0000

Kathleen Moriarty 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:
----------------------------------------------------------------------

Thanks for your responses on the SecDir review.

There were 3 points and I think you've come to a conclusion on each of them,
but let me verify from the updated text in versions 8 and 9.

>From the review:
* The probed interface can be identified by an IEEE 802 address (presumably, a
MAC address). This is an important detail from a security point of view.
Normally you don't expect a remote node to be able to access machines by MAC
address, and many firewall deployments enforce access control solely at the IP
level.

KMM: The following was added in 4.1:

         "o  The L-bit is set and the ICMP Extension Structure does not
              identify any local interfaces

           o  The L-bit is clear and the address or addresses found in the
              Interface Identification object appear in neither the IPv4 Address
              Resolution Protocol (ARP) Table nor the IPv6 Neighbor Cache"

And that's an improvement, thank you.

* Similarly, in an IPv4 setting, the proxy can be identified by a routable
address, and used to probe a non-routable (RFC 1918) address.

KMM: I don't see added text to point out this as was requested.  Can you point
me to the text or add some?

* "The incoming ICMP Extend Echo Request carries a source address that is not
explicitly authorized for the incoming ICMP Extended Echo Request L-bit
setting" - this implies a per-node whitelist listing all IP addresses that are
allowed to probe it. I don't think we mean seriously to list all the addresses
that can ping a given node, so this smells like security theater - sorry.

KMM: The last one - I agree with Ron, it is common practice to have explicit
allow only lists, at least for any organization I worked. I think this is a
good recommendation to keep in the document.

Thank you!