Subject: [OPSEC] Roman Danyliw's No Objection on draft-ietf-opsec-v6-26: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 20 Apr 2021 19:11:16 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-opsec-v6-26: 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 DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/

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

** Section 2.1.5.  Per “However, in scenarios where anonymity is a strong
desire (protecting user privacy is more important than user attribution),
privacy extension addresses should be used.”, it might be worth acknowledging
that even if these are managed network, the end user and the operators may be
at odds on what privacy properties are important.

** Section 2.2.1.  Per “A firewall or edge device should be used to enforce the
recommended order and the maximum occurrences of extension headers”, does
enforcement mean dropping the packets?

** Section 2.3.2.  Per “Network operators should be aware that RA-Guard and
SAVI do not work or could even be harmful in specific network configurations”,
please provide a more details, ideally through citation.

** Section 2.3.2, “Enabling RA-Guard by default in … enterprise campus networks
…”, what’s the key property of “enterprise campus network”.  The introduction
already roughly says this whole document applies to managed networks.

** Section 2.5.2.  Reading this section, the specific recommended practices
weren’t clear.

** Section 2.6.  It wasn’t clear how comprehensive this list of logs was
intended to be.  A few additional thoughts include: -- DHCPv6 logs -- firewall
ACL logs -- authentication server logs -- NEA-like policy enforcement at the
time of connection -- vpn/remote access logs -- passive DNS from port 53
traffic -- full packet capture -- active network and service scanning/audit
information

** Section 2.6.1.2.  The recommended fields in this section are helpful, but
only in the context of the rest of the five-tuple + timing + interface + vlan +
select layer 4 information for each flow.  These open IPFIX information
elements aren't mentioned.

** Section 2.6.2.1.  Per “The forensic use case is when the network operator
must locate an IPv6 address that was present in the network at a certain time
or is currently in the network”, isn’t this use case more precisely an attempt
to link an IP address to (a) a specific port in the case of a wired network;
(b) a access point (or base station, etc.) in the case of wireless; or (c) an
external IP address in the case of a VPN connection?

** Section 2.6.2.1.  Additional techniques/suggestions to consider:
-- Using the IPAM system noted in Section 2.1 or any other inventory system to
provide hints in the about where an IP address might belong in the topology.

-- A reminder that mapping between and IP+port or MAC+IP might not have been
the same one as during the time of the event of interest

-- there is discussion about identifying subscribers for an ISP but not in
normal enterprise network scenario through SSO logs (if port level security
doesn’t exist)

** Section 2.6.2.2.  Per “The first technique is to use the IPFIX information
and extract the list of all IPv6 source addresses to find all of the IPv6 nodes
that sent packets through the router”.  This framing is mixing the technique
with a particular logging format.  I would recommend being clear that the
technique is question is passive inspection of network talkers.  There a
several ways to get that: a properly configured IPFIX feed from a router, but
also from any number of network analysis tools on a span port or a tap.

** Section 2.7.1.  In addition to the two listed practices at the IPv4 edge, I
would recommend adding the common practice of application specific flow
inspection.

** Section 2.8.  The intent of this section isn’t clear as all of the described
practices are equally true of v4.  A few missing hardening practices include:

-- applying firmware, OS and application patches/upgrades to the devices in a
timely manner.

-- using multi-factor credentials to authenticate to devices

** Section 3.  This section is titled “Enterprises Specific …”, how is an
“enterprise” different than a “managed network” called out in the applicability
statement?

** Section 3.1.  This list is helpful.  Is text here and Section 2.5.4 needed? 
For example, does one need to say both “discard _packets_ from bogons” (this
section) and “discard _routes_ from bogons” (Section 2.5.4)