Hi Eric Thank you
Responses in-line Sent from my iPhone > On Oct 7, 2019, at 3:00 AM, Eric Vyncke (evyncke) <[email protected]> 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 <[email protected]> > Date: Tuesday, 24 September 2019 at 06:25 > To: Jen Linkova <[email protected]> > Cc: opsec WG <[email protected]>, "[email protected]" > <[email protected]>, OpSec Chairs <[email protected]> > Subject: Re: [OPSEC] WGLC for draft-ietf-opsec-v6-19 > Resent-From: <[email protected]> > Resent-To: Eric Vyncke <[email protected]>, Kiran Kumar Chittimaneni > <[email protected]>, Merike Kaeo <[email protected]>, > <[email protected]> > 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 <[email protected]> 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 > [email protected] > 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: 301 502-1347 > Email: [email protected] > www.linkedin.com/in/GYAN-MISHRA-RS-SP-MPLS-IPV6-EXPERT >
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
