Re: [OPSEC] WGLC for draft-ietf-opsec-v6-19

Gyan Mishra <> Tue, 24 September 2019 04:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF2A91200F4; Mon, 23 Sep 2019 21:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iH8r3a4uDaLP; Mon, 23 Sep 2019 21:25:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E48E71200F6; Mon, 23 Sep 2019 21:25:24 -0700 (PDT)
Received: by with SMTP id q1so1155604ion.1; Mon, 23 Sep 2019 21:25:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=98uhWg1YByFdrNqBMrlewF7TID6zjOb0KYY/q5qfs+E=; b=ibJBP4VPTIqX36DT3kGTHyJb+oLuCO4KTYmshWz8MERYM8DoimamalJ9FEtILVFm7v n29wb46BBtBhbBSzhzgqRylsH1RgTdzUMUWQnq87c2kXSF78xujCAOb5mDkY3z0TF6S+ NF/20MLypSb6hSWOXh8+G+iDw35I3zy9wwRxLpKg03UnEfJUYeBXP88i+nhu5q/gIg6K KrLFCnWk4HYqNTvU03AQjcln/cM46tnWYo95Akj5KJD6V9CstkIg2lPXXotG61AkRhgi Pw/5Cnvta57+590rYKLJjdWluE87Tdneo5HokTI5jQM0sg7OM/qU0mxAuUdmm+/mn3Bf Ucyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=98uhWg1YByFdrNqBMrlewF7TID6zjOb0KYY/q5qfs+E=; b=nI9aB9tPK/oL4uHIgms//wRk+3bDWlWm3atVElPFlUt6uimYwD2QGBi1DJYVYhc2ey RoNhntw5cgCmdJRgCsjFUlc8+OnnP4aLuunY+2c811ZQZDHXsyDcLSiPue4Cbr/oUVUz hR2zvDcQC/7qn1E9U6mXdIQWn/QIC8ISI4H4a7Hbl18qVJ6tnqgYuOYDml04b9ARJsTQ AvFPUHsd4L3WbVWVTj1cB149O7T8JBNlVKNu+pxQxxA+AayIABTaqqdwbV+YcZeDsOK6 TW90nJFQ4ifJetmdVmwk0jl065tOTqU8hPklpWcaAy6oN8GKpJVi6DZLMqRq1/rYRDs5 fCzQ==
X-Gm-Message-State: APjAAAWTVV1yjPkxzmToZcOMTgJq06hp6xDVclLlfDIk0fHYXFV8R+y9 ubp5oQZazcALn3+nBuOCi02P/87mKdca3rUGo9E=
X-Google-Smtp-Source: APXvYqxrgBZAalTnqU67kg/hWFOtf5nBVY+hUzocsQQrEOYglnm0rnrMkok51Vcl33GFi3Z8ZgmLEWHebbO8uVKNfGI=
X-Received: by 2002:a6b:b213:: with SMTP id b19mr1224483iof.58.1569299123892; Mon, 23 Sep 2019 21:25:23 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Tue, 24 Sep 2019 00:25:10 -0400
Message-ID: <>
To: Jen Linkova <>
Cc: opsec WG <>,, OpSec Chairs <>
Content-Type: multipart/alternative; boundary="000000000000d37730059344ecc6"
Archived-At: <>
Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6-19
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: opsec wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Sep 2019 04:25:28 -0000

Hi Jen

Comments in-line

I just joined the OPSEC workgroup and read through some of the drafts.
Right up my alley. 😃



On Mon, Sep 23, 2019 at 7:55 PM Jen Linkova <> wrote:

> Hello,
> This message starts a Working Group Last Call for draft-ietf-opsec-v6-19
> (
> Please review the draft respond to this email to support the document
> and/or send comments by 23:59 UTC on Fri, Oct 11th 2019.
> Thanks!
> --
> SY, Jen Linkova aka Furry
> _______________________________________________
> OPSEC mailing list

[Gyan]  In  section 2.1.5 below  on corporate intranets where you are on a
"trusted" network where the hosts are "trusted" the use or need for privacy
extensions are not necessary and accountability by far outweighs the
privacy extension to maintain anonymity from an IT security.  I have
deployed within Verizon's internal network as well as other customers a
standard of disabling privacy extensions random station id as well as
temporary address so that all hosts are accountable and traceable and the
addresses remain stable with EUI64 address or dhcpv6 address.  With RFC
8064  & RFC 7217 are adopted by windows & other desktop OS's and become the
default we can revert our IPv6 deployment standards back to the OS
defaults.  Section 2.1.4 talks about scanning and static IPv6 addresses
however should also take into account enterprises where hosts are "trusted"
and that scanning is a requirement for enterprises having a historical
database dump of arp cache & nd cache of all hosts addresses both IPv4 &

 2.1.5. Temporary Addresses - Privacy Extensions for SLAAC -

In some extreme use cases where user accountability is more important than
user privacy, network operators may consider to disable SLAAC and rely only
on DHCPv6; but, not all operating systems support DHCPv6 so some hosts will
not get any IPv6 connectivity. Disabling SLAAC and privacy extensions
addresses can be done for most OS and for non-hacker users 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. However attackers could still find ways to bypass this mechanism
if not enforced at the switch/ router level. However, in scenarios where
anonymity is a strong desire (protecting user privacy is more important
than user attribution), privacy extension addresses should be used.

Can we add a  section related to IPv6 inherent capability of the host to
maintain many IPv6 addresses and security concerns as to which IPv6 address
is used for conversation flows and the host OS default address selection
rfc 6724 internal mechanism used to determine which IPv6 address is used
for conversations.  With SLAAC its possible to have a router with many
addresses configured and all hosts on the subnet in that hypothetical
scenario would get an RA advertisement with no limits as many ipv6
addresses that are configured on the router.

In section 2.1.2 Point-to-Point links you mention a use case of
infrastructure routed p2p links only require being configured with link
local via Cisco "ipv6 enable" for ipv6 packet processing and I believe
Juniper & Huawei have a similar command so that the IGP OSPF or ISIS
adjacency can form via LL LSA updates however the major security and
operational downside is that the traceroute is unable to show the in/out
hop by hop routed interface IPv6 addresses along the path to be able to
perform a hop by hop ping/trace when troubleshooting network issues related
to latency, jitter or drops.  So from a security standpoint it is
recommended although not required to place IPv6 address on all P2P routed

>From an addressing perspective and also for security standpoint the
ability  to craft an ACL allocating all infrastructure /128 loops from a
single /64 and /127 form a single /64 is recommended and coming out of the
same higher order block bit boundary such as a /56.  In implementations
that I have deployed we used as a standard addressing schema  "0  /56" -  0
/64 Loops, 1 /64 P2P and then instead of going crazy with vlsm we would
have a single mask we made it a /120 similar to /24 for IPv4 that covers
greater then 2 host nets router infra like router backbone ring or firewall
subnet and then last a /64 for all host subnets so simple addressing
allowing ability to craft security ACLs as necessary for all infrastructure
subnets /128-loops /127-p2p /120- >2 host subnet.


Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347