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
