[OPSEC] Fwd: [v6ops] draft-ietf-opsec-v6

[Fred Baker <[e-mail]>]

This was sent to v6ops instead of opsec

> From: JORDI PALET MARTINEZ <jordi.palet=[e-mail]>
> Subject: Re: [v6ops] draft-ietf-opsec-v6
> Date: March 29, 2019 at 5:13:32 PM GMT+1
> To: IPv6 Operations <[e-mail]>
> 
> Hi all,
> 
> Thanks for the reminder, overdue task for me for a while ... So here is it (partially, as I'm working in the plane, so more in following emails).
> 
> 2.1.  Addressing Architecture
> 
>   Once an address allocation has been assigned, there should be some
>   thought given to an overall address allocation plan.  With the
>   abundance of address space available, an address allocation may be
>   structured around services along with geographic locations, which
>   then can be a basis for more structured security policies to permit
>   or deny services between geographic regions.
> 
> One of MOST frequent issues when you start implementing IPv6 is that people tend to go to their RIR for a default allocation/assignment, and then try to make the addressing plan with what they have, instead of planning correctly and then going to the RIR. The result is many cases is ISPs providing a single /64 to customers, which is really bad.
> 
> Also, if the document is for operators and enterprises, you need to differentiate among allocation and assignment.
> 
> So, I will like to suggest rewording as:
> "A key task before starting an IPv6 deployment, once the sufficient knowledge has been acquired, is to prepare an addressing plan. With the abundance of address space available, an addressing plan may be structured around services along with geographic locations, which then can be a basis for more structured security policies to permit or deny services between geographic regions.
> 
> This may be seen as a simple task, but it is an activity within the IPv6 deployment project, that requires a very in depth thinking and it makes sense to invest as much time as required on it. Only once that addressing plan has been designed is the right time to go to the relevant Regional Internet Registry (RIR) to ask for an allocation or an assignment."
> 
> Then, in the next p.:
> 
>   A common question is whether companies should use Provider
>   Independent (PI) vs Provider Allocated (PA) space [RFC7381], but from
>   a security perspective there is little difference.
> 
> Replace with
> 
> "A common question is whether companies should use Provider Independent (PI) vs Provider Allocated (PA) space [RFC7381], but from a security perspective there is little difference. From the RIRs policies perspective, PI space is assigned to organizations if they don't need to sub-assign to third parties, while PA is allocated to operators or organizations that will sub-assign to third parties. For example, a big corporation may have different subsidiaries and they are legally different entities, so in this case each one need their own PI space, or the responsible for the network need to get allocated PA space. A public institution such as a Ministry, may get a PI, if is only for their own use and not for other government institutions, however if it is the government entity managing the network that interconnects several institutions and provide each one their own space, they need to obtain PA space."
> 
> And continue with "However, one ..." in a new p.
> 
> 2.1.1.  Statically Configured Addresses
> 
> Nit:
> The use of well-known(such
> The use of well-known (such
> 
> There are many scanning techniques and more to
>   come possible, hence, operators should never relly on the 'impossible
>   to find because my address is random' paradigm.
> 
> I will say:
> 
> There are many scanning techniques and more to
>   come possible, hence, operators should never relly on the 'impossible
>   to find because my address is random' paradigm, even if it is a good practice to have the statically configured addresses randomly distributed across the /64 subnets and use always DNS.
> 
> 2.1.2.  Use of ULAs
> 
> I will add:
> 
> "Even if today a network is not connected to Internet, and it looks like it will not be in the future, things change and it is a considerable effort to renumber it. So it may be relevant to obtain an IPv6 PI assignment from the RIR and have a stable addressing space since day one."
> 
> 2.1.3.  Point-to-Point Links
> 
> I disagree with the mention that RFC6164 indicate that /127 is the way. RFC6164 is about "routers must support it". See draft-palet-v6ops-p2p-links (new version coming soon, so may be a reference to it). So I think some rewording is needed here, specially because router vendors sorted out those bugs long time ago.
> 
> 2.1.4.  Temporary Addresses - Privacy Extensions for SLAAC
> 
> I will add, that "In those cases where accounting/auditing/extreme granular security is required, because is impractical to use DHCPv6 due to the lack of support in Android based OSs, link-layer security such as IEEE802.1x may be used."
> 
> 2.1.6.  DHCP/DNS Considerations
> 
> This probably belongs to another section (may be a specific one for DNS), but related:
> 
> "If there is a need for Statically Configured Addresses, it should considered using DNS to refer to them, so no hard-coded addresses are used by applications. This facilitates also debugging/troubleshooting as avoids remembering addresses. In may be advisable to have multiple-faced DNS ("views") in order to ensure that internal-only used hosts, aren't published globally and full zone transfers are disallowed."
> 
> 2.1.7.  Using a /64 per host
> 
> I will add:
> 
> "This also avoids the need to "proxy" or NAT-like operations if multiple VMs, containers, or similar ones, need their own IPv6 address from a single /64 ."
> 
> Regards,
> Jordi
> 
> 
> 
> El 29/3/19 6:19, "v6ops en nombre de Fred Baker" <[e-mail] en nombre de [e-mail]> escribió:
> 
>    Yesterday, the authors of an opec draft asked us for comments on their draft, which is in a second WGLC in opec ([e-mail]). You may have missed the character string:
> 
>    https://datatracker.ietf.org/doc/draft-ietf-opsec-v6
>    https://tools.ietf.org/html/draft-ietf-opsec-v6
>      "Operational Security Considerations for IPv6 Networks", Eric Vyncke,
>      Chittimaneni Kk, Merike Kaeo, Enno Rey, 2019-03-11,
> 
>    I'd encourage people to read it and comment on the opec list.
> 
>    --------------------------------------------------------------------------------
>    Victorious warriors win first and then go to war,
>    Defeated warriors go to war first and then seek to win.
>         Sun Tzu
> 
>    _______________________________________________
>    v6ops mailing list
>    [e-mail]
>    https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
> 
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...