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

[Gyan Mishra <[e-mail]>]

Hi Jen

Comments in-line

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

Regards,

Gyan

On Mon, Sep 23, 2019 at 7:55 PM Jen Linkova <[e-mail]> wrote:

> Hello,
>
> This message starts a Working Group Last Call for draft-ietf-opsec-v6-19
> (https://tools.ietf.org/html/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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/opsec
>


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

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

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



Regards,

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: [phone]

Email: [e-mail]

www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT