Thank you Fred and Jordi -éric
On 30/03/2019, 14:30, "OPSEC on behalf of JORDI PALET MARTINEZ" <[email protected] on behalf of [email protected]> wrote: Additional inputs follow. I will follow the discussion if anything else need to be clarified. 2.3.3. Securing DHCP Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as originally detailed in [RFC3315] now obsoleted by [RFC8415] I think it should mention directly RFC8415, not the older document, as in case it is needed, RFC8415 already have the reference to the older one, updates, etc. Same across the complete document, replace 3315 with 8415. 2.3.4. 3GPP Link-Layer Security Even if is not common today, DHCPv6 and -PD are also supported in 3GPP, so may be a reference to the same considerations that apply in that case from DHCP scenarios? 2.5.1. Authenticating Neighbors/Peers Similar comment: [RFC7166] (which obsoletes [RFC6506] I don't think across the text it makes sense to refer to the obsoleted/updated documents, unless there anything that need to be taken in consideration, as all the "new" documents will already mention the older ones. I've seen this in at least 5 more places across the text. 2.6. Logging/Monitoring In "Please note that there are privacy issues related to how those logs are collected, kept and safely discarded. Operators are urged to check their country legislation." You may want to point to something very specific, at least as an example, as GDPR, as it may have many "new" implications. Also, cases where some technologies can't be deployed in some countries, because they lack of compliance about the minimum data to be logged. 2.6.1.6. RADIUS Accounting Log Nit: [IEEE-802.1X]wired -> [IEEE-802.1X] wired 2.6.2.2. Inventory Nit: such packets... -> such packets. 2.7.1. Dual Stack Nit: are provided in Section 2.8 -> are provided in Section 2.8. Can't parse: global IPv6 address is rogue RA I think it means: global IPv6 address if rogue RA 2.7.2. Transition Mechanisms There are many tunnels used for specific use cases. Except when protected by IPsec [RFC4301], all those tunnels have a couple of security issues (most of them because they are tunnels and are described in RFC 6169 Maybe reads better this way: There are many tunnels used for specific use cases. Except when protected by IPsec [RFC4301], all those tunnels have a couple of security issues, most of them because the fact of being tunnels as described in RFC 6169 traffic interception: no confidentiality is provided by the tunnel protocols (without the use of IPsec) replace with: traffic interception: no confidentiality is provided by the tunnel protocols (without the use of IPsec or alternative methods) Also, one more nit, for consistence in this section (I've seen this in other parts of the document), some bullets finish with ";" others with ".". No mention to 6over4 (RFC2529)? The full section intro seems to care about "IPv6 in IPv4". Not sure if in the same section, or a different one, there should be some text considering that this will turn around, may be is needed to care about IPv4 in IPv6? 2.7.2.8. Teredo Teredo is now mostly never used and it is no more automated in most environment, so, it is less of a threat. I think this is somehow incomplete, in the sense that many users/enterprises are still running very old or non-updated OSs. A warning on that can make it: Teredo is now mostly never used and it is no more automated in most environment, so, it is less of a threat, however, special consideration must be taken in case of devices with older or non-updated operating systems may be present, which by default were running Teredo. May be a similar text can be used as well for 6to4 (2.7.2.7. 6to4). May be some considerations for LDPv6 in a specific section, such as done for 2.7.2.4. 6PE and 6VPE. Some mechanisms do translation and encapsulation, so some text to explain that both security risk-sets can apply there. Also, after reading all those sections, I've a suggestion. I don't think "2.7.2. Transition Mechanisms" is the right title for that section. This is already part of "2.7. Transition/Coexistence Technologies". I will suggest: 2.7.2. Encapsulation Mechanisms 2.7.3.1. Carrier-Grade Nat (CGN) May be 2.7.3.1. Carrier-Grade NAT (CGN) I think a reference to the wording AFTR needs also to be included as per RFC6333. For example: Address Family Transition Router (AFTR, RFC6333), Carrier-Grade NAT (CGN), also called NAT444 CGN ... 2.7.2.6. Mapping of Address and Port I understand the way you organized those, but because MAP-T and MAP-E have different implications (translation vs encapsulation), I will suggest to either split it, even if text is partially duplicated, or at least have a sub-section in the translation section for MAP-T with a reference to this. 2.7.3.2. NAT64/DNS64 Either a new section for 464XLAT, or a p. and change the section title: 2.7.3.2. NAT64/DNS64 and 464XLAT 464XLAT (RFC6877) shares the same security considerations as NAT64 and DNS64, however it can be used without DNS64, avoiding the DNSSEC implications. May be a reference to draft-ietf-v6ops-nat64-deployment, is useful. Also a mitigation, in some cases to avoid everything to be translated by the NAT64 is the use of EAMT (RFC7757). Missing lw4o6 (RFC7596) section as well? May be some generic considerations for IPv6-only and IPv4-as-a-Service (draft-ietf-v6ops-transition-ipv4aas), such as the need to include a DNS-proxy in devices running the transition mechanism. One more suggestion. Reorder alphabetically the sub-sections, for example, the encapsulation mechanisms, the translation mechanisms, etc. It may be worth to look into that in the rest of the document as well. 3.2. Internal Security Considerations: As mentioned in Section 2.6.2, care must be taken when running automated IPv6-in-IP4 tunnels. Some text also about IPv4-in-IPv6? What about allowing/disallowing VPNs (yes, it is a tunnel, but explicit mention)? Nit: provided in Section 2.8 -> provided in Section 2.8. 4.1. BGP Is not just prefix filtering, also boggon ASN filtering. Add a recommendation for RPKI and strong filtering to avoid hijacking (both for 3rd parties and boggons of IPv4, IPv6 and ASN). 5. Residential Users Security Considerations Replace If the Residential Gateway has IPv6 connectivity, [RFC7084] (that obsoletes [RFC6204]) defines the requirements of an IPv6 CPE and does not take position on the debate of default IPv6 security policy as defined in [RFC6092]: with If the Residential Gateway has IPv6 connectivity, [RFC7084] and draft-ietf-v6ops-transition-ipv4aas define the requirements of an IPv6 CPE and does not take position on the debate of default IPv6 security policy as defined in [RFC6092]: I think in this section, it makes sense a reference to Section 5. UPnP Support of draft-ietf-v6ops-transition-ipv4aas, which also includes a reference to PCP support. Final inputs: 1) Should the document have a special mention that in IPv6 it doesn't make sense, and it has negative implications the complete filtering of ICMP, and instead use rate limiting, or filter only echo/reply? 2) I never thought about it, but maybe there are some (or in some scenarios) implications because Happy Eyeballs, that need to be considered ? ********************************************** 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. _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
