Re: [OPSEC] draft-ietf-opsec-v6-24 - Shepherd Review update

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> 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) <[e-mail]>
> wrote:
>
>> Thank you Gyan
>>
>>
>>
>> -éric
>>
>>
>>
>> *From: *Gyan Mishra <[e-mail]>
>> *Date: *Monday, 26 April 2021 at 06:34
>> *To: *opsec WG <[e-mail]>, OpSec Chairs <[e-mail]>,
>> Eric Vyncke <[e-mail]>
>> *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 [e-mail] <[e-mail]>*
>>
>> *M 301 502-1347*
>>
>>
>>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email [e-mail] <[e-mail]>*
>
>
>
> *M 301 502-1347*
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*