Re: [OPSEC] draft-ietf-opsec-v6

[JORDI PALET MARTINEZ <[e-mail]>]

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.