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

[Gyan Mishra <[e-mail]>]

Hi Eric 

Thank you 

Responses in-line

Sent from my iPhone

> On Oct 7, 2019, at 3:00 AM, Eric Vyncke (evyncke) <[e-mail]> wrote:
> 
> Gyan,
>  
> Thank you for reviewing our draft. It is very much appreciated by the authors.
>  
> As a co-author of this draft, I agree with your point of view on the stability of IPv6 addresses in the specific case of a  “trusted network”, esp when RFC 7127 and 8064 are widely deployed.
>  
> See more comments in line with EV>
>  
> Regards
>  
> -éric
>  
> From: Gyan Mishra <[e-mail]>
> Date: Tuesday, 24 September 2019 at 06:25
> To: Jen Linkova <[e-mail]>
> Cc: opsec WG <[e-mail]>, "[e-mail]" <[e-mail]>, OpSec Chairs <[e-mail]>
> Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6-19
> Resent-From: <[e-mail]>
> Resent-To: Eric Vyncke <[e-mail]>, Kiran Kumar Chittimaneni <[e-mail]>, Merike Kaeo <[e-mail]>, <[e-mail]>
> Resent-Date: Tuesday, 24 September 2019 at 06:25
>  
> 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.
>  
> EV> This issue  (multiple addresses per host) is described in section 2.6.2.3  and at the end of the introduction of section 2.1 ? Unsure whether the document should go further but the next rev will have some more text in section 2.1.

[Gyan] Thank you 
>  
> 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.
>  
> EV> Indeed OSPFv3 & RIPng only use IPv6 LLA to form adjacencies (IS-IS does not have IP address) and I can only agree with the above as the co-author of RFC 7404 ;-)
>  
> 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.  
>  
> EV> Thank you for the return of experience
>  
> -éric
>  
>  
> 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
>