This was sent to v6ops instead of opsec > From: JORDI PALET MARTINEZ <[email protected]> > Subject: Re: [v6ops] draft-ietf-opsec-v6 > Date: March 29, 2019 at 5:13:32 PM GMT+1 > To: IPv6 Operations <[email protected]> > > 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" <[email protected] en > nombre de [email protected]> escribió: > > Yesterday, the authors of an opec draft asked us for comments on their > draft, which is in a second WGLC in opec ([email protected]). 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 > [email protected] > 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 > [email protected] > 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...
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
