[OPSEC] Benjamin Kaduk's No Objection on draft-ietf-opsec-v6-26: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Mon, 19 April 2021 23:40 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: opsec@ietf.org
Delivered-To: opsec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E790C3A4978; Mon, 19 Apr 2021 16:40:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-opsec-v6@ietf.org, opsec-chairs@ietf.org, opsec@ietf.org, Gyan Mishra <hayabusagsm@gmail.com>, hayabusagsm@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.28.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <161887564392.1499.4789299861346688678@ietfa.amsl.com>
Date: Mon, 19 Apr 2021 16:40:43 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsec/IwMioyF5o3V19uaNvdASHNmqoo4>
Subject: [OPSEC] Benjamin Kaduk's No Objection on draft-ietf-opsec-v6-26: (with COMMENT)
X-BeenThere: opsec@ietf.org
X-Mailman-Version: 2.1.29
List-Id: opsec wg mailing list <opsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsec>, <mailto:opsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsec/>
List-Post: <mailto:opsec@ietf.org>
List-Help: <mailto:opsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsec>, <mailto:opsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Apr 2021 23:40:44 -0000

Benjamin Kaduk 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:


While the guidance of the need to be prepared to postprocess logs to normalize the
string representation of IPv6 addresses (if necessary) is good, I am not
sure that the specific perl code provided in Section is useful
to include.  In addition to my specific comments in the
section-by-section comments, it is in a sense a very blunt instrument
that assumes whitespace-separated records and blindly tries to treat
every word as an IPv6 address with no regard for the message/record
format.  This can easily induce collateral damage, and it seems that in
most cases it will be possible to use a much more targeted
normalization procedure that takes into account knowledge of the message
structure.  So my recommendation would be to just remove the specific
example perl script.

Section 2.1.1

   Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios
   where interfaces are not globally reachable, despite being routed
   within a domain.  They formally have global scope, but [RFC4193]
   specifies that they must be filtered at domain boundaries.  [...]

I'm not seeing something quite so strong in RFC 4193.  It has a note
that "[i]f BGP is being used at the site border with an ISP, the default
BDP configuration must filter out [...]", but that is only a default,
and the guidance about non-BGP mechanisms is not even this strong.

Section 2.1.2

Is there a reference for "the ping-pong attack" (where the use of the
definite article implies there is a specific well-known attack)?

Section 2.1.4

   Stable addresses also allow easy enforcement of a security policy at
   the perimeter based on IPv6 addresses.  [RFC8520] is a mechanism
   where the perimeter defense can retrieve security policy template
   based on the type of internal device.

IIUC when using MUD there is a need to have a mapping from IP address to
type of device (or MUD file), which doesn't seem to be mentioned by the
text here.

Section 2.1.7

Please call out the privacy considerations (already discussed in RFC
8273) of using a /64 per host.

Section 2.2.3

   If those requirements are not met, stateless filtering could be
   bypassed by a hostile party.  [RFC6980] applies a stricter rule to
   Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented
   NDP packets.  [...]

As is clarified later in Section, fragmented Certification Path
Advertisement messages are not required to be dropped.  In my opinion we
should provide a consistent treatment of the topic across all locations
we mention it.

Section 2.2.4

   The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP
   [RFC4303]) are required if IPsec is to be utilized for network level
   security.  But IPsec is no longer required for normal IPv6 nodes: in

I think at this point AH is in practice deprecated, because ESP with
NULL cipher can perform the same role.

Also, is there any further commentary about IPsec in general that is
appropriate for this document?


   Isolating hosts for the NDP traffic can be done by using a /64 per
   host, refer to Section 2.1.7, as NDP is only relevant within a /64
   on-link prefix; 3GPP Section 2.3.4 uses a similar mechanism.

I recall some previous discussion about whether the prefix/IID boundary
must fall at exactly 64 bits, but I trust the authors to have a better
handle on this topic than I do.

Section 2.6

   Please note that there are privacy issues or regulations related to
   how these logs are collected, stored, and safely discarded.

Also to how they are *used*, e.g., the "correlation" behavior listed


   my (@words, $word, $binary_address) ;

@words is unused.

       $binary_address = inet_pton AF_INET6, $word ;
       if ($binary_address) {
         print inet_ntop AF_INET6, $binary_address ;

I'd strongly recommend using parentheses for at least the function calls
inet_pton and inet_ntop.

I also get warnings trying to run this code:

Subroutine main::pack_sockaddr_in6 redefined at /usr/share/perl/5.26/Exporter.pm line 66.
 at ... line 5.
Subroutine main::unpack_sockaddr_in6 redefined at /usr/share/perl/5.26/Exporter.pm line 66.
 at ... line 5.
Subroutine main::sockaddr_in6 redefined at /usr/share/perl/5.26/Exporter.pm line 66.


   This is an important source of information because it is trivial (on
   a switch not using the SAVI [RFC7039] algorithm) to defeat the
   mapping between data-link layer address and IPv6 address.  Let us
   rephrase the previous statement: having access to the current and
   past content of the neighbor cache has a paramount value for the
   forensic and audit trail.

And if it's interesting to the operator it's interesting to other
parties as well; in certain threat models this information could itself
be a target.

Section 2.7.2

   o  reflection attack: another specific use case of tunnel injection
      where the attacker injects packets with an IPv4 destination
      address not matching the IPv6 address causing the first tunnel
      endpoint to re-encapsulate the packet to the destination... Hence,
      the final IPv4 destination will not see the original IPv4 address
      but only the IPv4 address of the relay router.

Is it possible at least sometimes to configure the tunnel endpoints to
drop traffic rather than "hairpin" it back out?

   To mitigate the bypassing of security policies, it is recommended to
   block all default configuration tunnels by denying IPv4 packets

This is not something I'd expect in a general-purpose recommendation, so
I wonder if a reminder (and backreference) of the Applicability
Statement in Section 1.1 would help.

   o  UDP protocol 3544: this will block the default encapsulation of
      Teredo (Section tunnels.

(really a nit, but up here since it's important) s/protocol/port/.


   Special care must be taken to avoid a looping attack by implementing
   the measures of [RFC6324] and [RFC6964].

I see a section 3.6 in RFC 6964 entitled "Loop Avoidance"; are we
intending to refer to just that guidance or the entire document?  (I
could easily imagine that there are other parts of the document that
have relevance for this topic, but did not read closely enough to
attempt to make my own determination of that.)


   While 6rd tunnels share the same encapsulation as 6to4 tunnels
   (Section, they are designed to be used within a single SP
   domain, in other words, they are deployed in a more constrained
   environment than 6to4 tunnels and have few security issues other than
   lack of confidentiality.  [...]

My current guess is that the "more constrained environment" is intended
to refer to a restricted or restricted-access environment that is
assumed to not have any potential for (e.g.) traffic injection.  But if
lack of confidentiality remains an issue, it seems that the risk of an
attacker or compromised device on the path is considered in scope, so
I'm not sure how injection and the other attacks would be impossible in
that case.  I think we need some more clarity on what this sentence is
intended to say.


   Organizations using MPLS in their core can also use 6PE [RFC4798] and
   6VPE [RFC4659] to enable IPv6 access over MPLS.  As 6PE and 6VPE are
   really similar to BGP/MPLS IP VPNs described in [RFC4364], the
   security properties of these networks are also similar to those
   described in [RFC4381].  They rely on:

(RFC 4381 is, of course, an ISE doc, so we are in some sense endorsing
its content by referencing it in this way.)

   LDPv6 itself does not induce new risks, see also [RFC7552].

Should we say which security considerations continue to apply (i.e., the
LDPv4 ones)?


   Internet.  While host policies can be deployed to block Teredo in an
   IPv4-only network in order to avoid this firewall bypass, it would be
   enough to block all UDP outbound traffic at the IPv4 firewall if
   deemed possible (of course, at least port 53 should be left open for
   DNS traffic, port 123 for NTP, port 443 for QUIC, port 500 for IKE,
   port 3478 for STUN, i.e., filter judiciously).

I find it hard to accept as useful a recommendation to "block all UDP
outbound traffic if deemeed possible" followed by a necessarily
incomplete list of exceptions.  Perhaps it is enough to note that when
outbound UDP is blocked, outbound Teredo is likewise blocked, and keep
the list of common UDP services.


   The Security Consideration sections of [RFC6146] and [RFC6147] list
   the comprehensive issues.  A specific issue with the use of NAT64 is
   that it will interfere with most IPsec deployments unless UDP
   encapsulation is used.  DNSSEC and DNS64 negatively interact, see
   section 3.1 of [RFC7050].

My reading of Section 3.1 of RFC 7050 is more about using DNSSEC to
secure the discovery of Pref64::/n than about the negative interactions
between DNSSEC and DNS64.  The latter seems to be covered in the
(already referenced) security considerations section of RFC 6147,

I might say something stronger than just "negatively interact", too.

Section 2.8

   o  Use cryptographically protected protocols for device management if
      possible (SCP, SNMPv3, SSH, TLS, etc.)

Since these are already only guidelines, I would strike "if possible".

Section 3.1

In light of RFC 2804, I wonder whether more of a disclaimer is
appropriate when referencing RFC 3924 and otherwise discussing lawful

   o  Filter specific extension headers by accepting only the required
      ones (permit list approach) such as ESP, AH (not forgetting the
      required transport layers: ICMP, TCP, UDP, ...), where possible at
      the edge and possibly inside the perimeter; see also

[This seems to be another place where general-purpose and
managed-network-specific advice diverge, and reiteration of the
applicability statement might be in order.]

   o  Implement appropriate rate-limiters and control-plane policers

Is there a reference to give guidance on what is "appropriate"?


Section 1

   This document complements [RFC4942] by listing all security issues

I'm always a little wary of "all" or "comprehensive" when covering
security issues; it's hard to be sure that we really have captured

Section 2.1

   A common question is whether companies should use Provider
   Independent (PI) vs. Provider Allocated (PA) space [RFC7381], but

The terminology used in 7381 seems to be about requesting address space
from a LIR/RIR/NIR vs using "Provider-Aggregated" address space, so just
searching for the terms listed here doesn't find much useful discussion.
Perhaps linking to specifically Section 2.6 thereof would help.

Section 2.1.4

   While in some environments obfuscating addresses could be considered
   an added benefit, it does not preclude enforcement of perimeter rules
   and that stable addresses follow some logical allocation scheme for
   ease of operation (as simplicity always helps security).

This sentence might be a bit long for a paragraph.  I'd suggest breaking
after "enforcement of perimeter rules" and continuing with "It also does
not preclude stable addresses from following [...]" (assuming I'm even
parsing the current version correctly).

Section 2.1.5

   Historically, stateless address autoconfiguration (SLAAC) makes up
   the globally unique IPv6 address based on an automatically generated

Is "makes up" accurate for something that was only historically the
recommended practice but no longer is?

   Disabling SLAAC and privacy extension addresses can be done for most
   operating systems by sending RA messages with a hint to get addresses
   via DHCPv6 by setting the M-bit but also disabling SLAAC by resetting
   all A-bits in all prefix information options.  [...]

I think s/but/and/?

   However, in scenarios where anonymity is a strong desire (protecting
   user privacy is more important than user attribution), privacy
   extension addresses should be used.  When [RFC8064] is available, the

RFC 8064 is a "recommendation" (and seems to defer to RFC 7217 for the
actual computation), so maybe we are concerned about the "mechanisms
recommended by RFC 8064" being available?

Section 2.2.1

   A firewall or edge device should be used to enforce the recommended
   order and the maximum occurrences of extension headers.

If it's only a recommended order, why do we want to strictly enforce it?

Section 2.3.1

   o  Using a /127 on point-to-point link per [RFC6164].

either "a point-to-point link" or "links"

   o  Using link-local addresses only on links where there are only
      routers, see [RFC7404]

Is the first "only" correct?


   A more drastic technique to prevent all NDP attacks is based on
   isolation of all hosts with specific configurations.  Hosts (i.e.,
   all nodes that are not routers) are unable to send data-link layer

I suggest starting the second sentence with something like "When this
technique is used" or "In such a scenario", since (AFAICT) the statement
is not true in the general case.


   hosts.  This recommendation also applies when DHCPv6 is used as RA
   messages are used to discover the default router(s) and for on-link

comma after "is used".

   in Section 2.2.3.  The generated log should also be analyzed to
   identify and act on violations.  Network operators should be aware

What generated log?  This document does not have a prior mention of

   Enabling RA-Guard by default in Wi-Fi networks or enterprise campus
   networks should be strongly considered unless specific use cases such
   as the presence of devices Homenet devices emitting router
   advertisements preclude this.

spurious (first?) "devices".

Section 2.3.3

   Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described
   in [RFC8415], enables DHCP servers to pass configuration parameters
   such as IPv6 network addresses and other configuration information to
   IPv6 nodes such as a recursive DNS server.  DHCP plays an important

"such as a recursive DNS server" should come before "to IPv6 nodes".

   The two most common threats to DHCP clients come from malicious
   (a.k.a., rogue) or unintentionally misconfigured DHCP servers.  A
   malicious DHCP server is established with the intent of providing

I'd suggest a transition phrase, such as "in these scenarios", as the
current phrasing could be misread as an authoritative statement of the
only reason why one might maliciously set up a DHCP server.

   incorrect configuration information to the clients to cause a denial-
   of-service attack or to mount on path attack.  While unintentional, a

"an on-path attack".

Section 2.3.5

   [RFC7772], [RFC6775] (for specific wireless networks) discuss methods
   to rate-limit RAs and other ND messages on wireless networks in order
   to address this issue.


Section 2.4

   [RFC6192] defines the router control plane and provides detailed
   guidance to secure it for IPv4 and IPv6 networks.  This definition is
   repeated here for the reader's convenience.  Please note that the

There is some churn in the diff, added commas and a few removed words.
If possible, it might be worth using some formatting to indicate that
only the one paragraph is quoted.

   its input queue with more packets than it can process.  The control
   plane processor is then unable to process valid control packets and
   the router can lose OSPF or BGP adjacencies which can cause a severe
   network disruption.

Why do we privilege OSPF as the only IGP mentioned?  (Also later on.)

Section 2.4.2

   o  Drop packets destined to the routers except those belonging to
      protocols which are used (for example, permit TCP 22 and drop all
      others when only SSH is used);

(Isn't NETCONF on port 22 as well, given its use of ssh as substrate?)

Section 2.4.3

   o  processing of the hop-by-hop options header, new implementations
      follow section 4.3 of [RFC8200] where this processing is optional;

comma splice.

   On some routers, not everything can be done by the specialized data
   plane hardware which requires some packets to be 'punted' to the

It's nice that we pseudo-define "punted" but we've used the term earlier

   packet exceptions.  The only protection for the RP is to rate-limit
   those packet exceptions that are forwarded to the RP, this means that
   some data plane packets will be dropped without an ICMP message sent
   to the source which may delay Path MTU discovery and cause drops.

comma splice

Section 2.5.2

   [RFC7166] changes OSPFv3 reliance on IPsec by appending an
   authentication trailer to the end of the OSPFv3 packets; it does not

I suggest "adds an authentication mechanism for OSPFv3 other than
IPsec"; the phrasing about "reliance" is a bit surprising since (I
assume) many sites run without any cryptographic protection at all.

   specifically authenticate the specific originator of an OSPFv3

Maybe the specifically/specific are redundant and one could be dropped?

   With all authentication mechanisms, operators should confirm that
   implementations can support re-keying mechanisms that do not cause
   outages.  There have been instances where any re-keying causes

BCP 107 might be a good reference here for re-keying concepts.

   outages and therefore, the tradeoff between utilizing this
   functionality needs to be weighed against the protection it provides.

This phrasing seems to imply that even now there is a tradeoff to weigh
between using cryptographic protection and risk of outage.  I'd suggest
rewording to use the past tense and qualify that it is only the
scenarios where re-keying requires outage that has such a pronounced
tradeoff.  (To be clear, there is still a tradeoff for using any
cryptographic protection, but that is more along the lines of "fail-safe
vs fail-open".)

Section 2.5.3

   Many routing protocols support the use of cryptography to protect the
   routing updates, the use of this protection is recommended; [RFC8177]
   is a YANG data model key chains including the renewal.

"YANG data model for key chains that includes re-keying functionality".

Section 2.5.4

   o  Configure ingress route filters that validate route origin, prefix
      ownership, etc. through the use of various routing databases,
      e.g., [RADB].  There is additional work being done in this area to
      formally validate the origin ASs of BGP announcements in

To what extent is this still "work being done" vs a realized result,


   o  interfaces-state/interface/statistics from ietf-
      interfaces@2018-02-20.yang [RFC8343] which contains counters for
      interface .

I can't tell if this sentence ended prematurely or not.


   The neighbor cache of routers contains all mappings between IPv6
   addresses and data-link layer addresses.  There are multiple ways to

I think we've also used the terms "physical layer", "link-layer address",
and "MAC address" already as well.

   o  using streaming telemetry or NETCONF [RFC6241] and [RFC8040] to
      collect the operational state of the neighbor cache;

Since RFC 8040 is RESTCONF this line doesn't scan very well.


   address, some being data-link layer address prepended with time
   information, or even an opaque number which is useless for
   operational security.  Moreover, when the DUID is based on the data-

I suggest "that requires correlation with another data source to be
usable for operational security".


   used by the user.  This technique can be used notably for Wi-Fi
   networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X
   [IEEE-802.1X] wired interface on an Ethernet switch.

Wi-Fi networks are not 802.1X wired interfaces (last I checked), so


   a subscriber via the RADIUS log.  Alternatively, the Forwarding
   Information Base of the CMTS or BNG indicates the CPE of the

Please expand CMTS and BNG.


   In order to do correlation in IPv6-related logs, it is advised to
   have all logs in a format with only canonical IPv6 addresses
   [RFC5952].  Then, the neighbor cache current (or historical) data set

(We made this recommendation already earlier.)

Section 2.7.2

   There are many tunnels used for specific use cases.  Except when
   protected by IPsec [RFC4301], all those tunnels have a couple of
   security issues as described in RFC 6169 [RFC6169];


   o  bypassing security policy: if a firewall or an IPS is on the path

Expand IPS.


   tunnel injection are still possible.  Therefore, the use of IPsec
   [RFC4301] in transport mode and protecting the encapsulated IPv4
   packets is recommended for those tunnels.  Alternatively, IPsec in

s/and protecting/to protect/


   o  Hiding the IPv4 core, hence removing all attacks against

This is the only place we use the term "P-router", so we might just
expand out the definition to avoid the jargon.


                                                    As MAP has a
   predictable IPv4 address and port mapping, the audit logs are easier
   to manage.

Easier to manage than what?


   Teredo is now hardly never used and no longer enabled by default in

s/hardly never/hardly ever/

   most environments, so, it is less of a threat, however, special
   consideration must be taken in case of devices with older or non-

s/case of/cases when/

Section 3.1

   o  Filter internal-use IPv6 addresses at the perimeter this will also
      mitigate the vulnerabilities listed in [RFC7359]

Some kind of punctuation (sentence break; semicolon) after "perimeter".

   o  Implement ingress and egress anti-spoofing in the forwarding and
      control planes, see [RFC2827] and [RFC3704]

Using a BCP 84 reference would also pick up the updates in RFC 8704.

                           It is recommended to filter at Internet
   connection(s) packets having a source or destination address
   belonging to the site internal prefix(es); this should be done for
   ingress and egress traffic.

Do we want to say "respectively" here?  (Filtering any traffic with
source or destination belonging to internal prefixes would seem to
result in the site being an island, disconnected from the internet...)

Section 5

   Some residential users have less experience and knowledge about
   security or networking.  [...]

Less than who/what?