Hi Eric Just checking if you had a chance look my Shepherd review.
Kind Regards Gyan On Thu, Apr 29, 2021 at 7:38 PM Gyan Mishra <[email protected]> wrote: > > > Hi Eric > > Shepherd Review below: > > Abstract > > “ This document is only applicable to managed > > networks, such as enterprise networks.” > > > Should we mention service provider public internet and private networks > are applicable > > Introduction > > Maybe mention extension headers as that has been a huge difference as well > as security issue > > When mentioning ARP and ND difference maybe mention that now ICMPv6 now > takes on the role of L2 Mac to L3 address mapping and maybe along the same > line of thinking of broadcast versus multicast mention that broadcast no > longer exist in IPv6. > > 2.1 Addressing Architecture > > Rewording of what RFC 7934 states related to multiple addresses > > Old > > In [RFC7934 <https://tools.ietf.org/html/rfc7934>], it is recommended that > IPv6 network deployments provide multiple IPv6 addresses from each prefix to > general-purpose hosts and > it specifically does not recommend limiting a host to only one IPv6 > address per prefix. The way it’s worded it appears that it’s recommended > > that the network provide more then one address. > > > New > > > > RFC 7934 states that most general-purpose IPv6 networks, hosts have the > ability to configure additional IPv6 addresses from the link prefix(es) > without > explicit requests to the network as there are > > host functions that require more then one address. > > > Maybe also mention at the end of the paragraph that having multiple > addresses on a host provides challenges to the NOC in troubleshooting and > MTTR. > > Section 2.1.1 > > ULAs although less likely to have overlap due to pseudo random algorithm > there is no guarantee of not having an overlap. Operators of with large > internal corporate networks that are subject to mergers and acquisitions > it is recommended to not use ULA. ULA does not guarantee uniqueness where > GUA does for internal deployments. > > 2.1.2 > > Many operators reserve a /64 block for all P2P addresses in > their infrastructure and allocate a /127 out of this reserved /64 > prefix for each p2p interface. > > > This is a routing related caveat related to addressing. So as all routing > protocols use LL next hop most vendors have a command similar to cisco “IPv6 > enable” that allows for processing and forwarding of IPv6 packets without an > IPv6 address configured on an interface. The caveat here is in traceroute > the interface next hop is not shown in the trace and so for the NOC makes > troubleshooting more difficult. However it does make deployments or IPv6 on > routed backbone nodes much quicker as no address planning is required. I > actually use this method in lab environments all the time and > > it’s very handy. Also mention that on eBGP tie connections GUI or ULA as > well is not required to save on address planning and > > peering can be done using link local. However care must be taken as the > caveat is LL is not reachable beyond local link and > > ping or OAM of link if required that will not work. The same > operationalissue goes for a routed interfaces using LL and > > no IPv6 address are now not pingable to ensure each link is Up and reachable > by NMS. > > > > On P2P when using /127 it is recommended to disable DAD as the subnet router > anycast is used and so DAD could fail and place the IPv6 interface in a > “tentative” state. > > > 2.14 > > > I believe what was meant is stable but random not “not-stable as for server > functions should always be stable address. Maybe worth mentioning and use of > static stable address for servers and not SLAAC address. > > > Old > > > Typical deployments will have a mix of stable and non-stable > addresses; the stable addresses being either predictable (e.g., ::25 > for a mail server) or obfuscated (i.e., appearing as a random 64-bit > number). > > > New > > > Typical deployments will have a mix of stable predictable and stable random > addresses; the stable addresses being either predictable (e.g., ::25 > for a mail server) or obfuscated (i.e., appearing as a random 64-bit > number). The > > > Mention the double edged sword trade off as far as importance when it comes > to using random changing address used for privacy > > for broadband users versus stable address for corporate network user > community where security and traceability is of utmost importance. > > > I believe what is being conveyed related to scanning is by pinging FF02::1 > it is easy to discover all hosts on the network. Also may want to mention > that all host have a local ND cache similar to a router ND cache as ICMPv6 > is running between the router and all hosts NS/NA as well as RS/RA. > > 2.1.5 > > Should note that even though M and O bit is set the SLAAC address is also > set as well. SLAAC has to be disabled manually on router via cisco command > example “IPv6 nd default no-advertise”. > > For any router or P2P links mentioned also “IPv6 ND RA suppress-all” cisco > command example which suppress both periodic and response to unsolicited RS > as routed link has static IP. > > On L2 switches which may have Mgmt interface that sits on the same subnet > as upstream router pair L2 connected to closet switch once and address is > placed on the L3 router interface the L2 router can act as a default > gateway hijack as it sends an RA. This can impact all hosts on the subnet > black hole. All L2 switches Mgmt L3 interface that sits on host subnets > interface should have “IPv6 nd ra suppress-all”. For L2 hosts the > recommended is to not enable IPv6 uncast-routing on hosts placing them in > “host-mode” versus acting as a router and now the L2 switch can pick up > default route via RA from upstream router pair. With that of course any > use of SLAAC and RA advertisement to host requires RA guard. > > 2.2 > > Mention the DDOS denial of service issue related to HBH and DOH as their > is no limit to the number of TLV options other than the maximum length of > hbh options header 2048 that can be present as well as well as 0 byte TLVs > are valid and also no limit to the number of extended headers stacked > limited by the MTU. Also the cyclical cycle by operators filtering hbh and > doh to avoid risk of ddos attack and management plane impact which impacts > designers from developing new use cases for hbh and doh. This impacts the > use of hbh and doh over the internet. > > Section 2.4 > > See this draft which I am Co-author has some details related to NPU and > fixed function ASIC and > separation of control plane and data plane criticality. > > Maybe add below draft as normative reference > https://tools.ietf.org/html/draft-peng-v6ops-hbh-03 > > Mention the management plane which is impacted when packets are sent to > the control plane. > > > 3.1 > > Perimeter ACLs as well as firewall filters it is recommended to only > permit directly adjacent ND packet as ND used RFC 5082 GTSM so TTL is set > to 255 and which can be used as an attack vector. I have an perimeter IACL > that is customized and had the DAD has the solicit node multicast address > so DAD succeeds. > > 2.7.2.4 > > “Securing the routing protocol between CE and PE; in the case of 6PE and > 6VPE, link-local addresses (see [RFC7404 > <https://tools.ietf.org/html/rfc7404>]) can be used and as these addresses > cannot be reached from outside of the link, the security of 6PE and 6VPE is > even higher than an IPv4 BGP/MPLS IP > VPN.” > > > When using LL peering on the PE-RR iBGP peeing or PE-PE ibgp peering make > sure next-hop-self is used so the next hop is rewritten to loopback0 which > is reachable as LL not reachable. > > Section 2.7.1 > > Mention Happy Eyeballs RFC 6555 and Happy Eyeballs 2 RFC 8305 - By > default with dual stack IPv6 is preferred over IPv4 and that impacts access > to host via TCP or UDP as well as operational impact so any ping trace or > ssh done from the device IPV6 is used over IPV4. By default on dual stacked > host a A/AAAAA request goes out and a A/AAAA reply comes back and the > client creates IPv6 socket for TCP session to server with a TCP RTO > retransmission timeout of 20 seconds approximately. With Happy Eyeballs 1 > there is a simultaneous v6 end v6 connection with a 300ms preference for v6 > establishes and within 300ms the failover of the session occurs from v6 to > v4 thus not noticeable to the naked eye thus happiness with the eyeballs of > the user. > > Section 2.7.2 > > We should include 4to6 which as well as 6to6 tunnels. > > Kind Regards > > Gyan > > > On Mon, Apr 26, 2021 at 3:30 AM Eric Vyncke (evyncke) <[email protected]> > wrote: > >> Thank you Gyan >> >> >> >> -éric >> >> >> >> *From: *Gyan Mishra <[email protected]> >> *Date: *Monday, 26 April 2021 at 06:34 >> *To: *opsec WG <[email protected]>, OpSec Chairs <[email protected]>, >> Eric Vyncke <[email protected]> >> *Subject: *draft-ietf-opsec-v6-24 - Shepherd Review update >> >> >> >> >> Hi Eric >> >> >> >> I will do another final Shepherd review now of the draft as this draft as >> it is on its way to publication. >> >> >> >> Kind Regards >> >> >> >> <http://www.verizon.com/> >> >> *Gyan Mishra* >> >> *Network Solutions Architect * >> >> *Email [email protected] <[email protected]>* >> >> *M 301 502-1347* >> >> >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email [email protected] <[email protected]>* > > > > *M 301 502-1347* > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
