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

[Gyan Mishra <[e-mail]>]

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*