Operational Security Considerations for IPv6 Networks
RFC 9099
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2021-08-13
|
27 | (System) | Received changes through RFC Editor sync (created alias RFC 9099, changed abstract to 'Knowledge and experience on how to operate IPv4 networks securely is … Received changes through RFC Editor sync (created alias RFC 9099, changed abstract to 'Knowledge and experience on how to operate IPv4 networks securely is available, whether the operator is an Internet Service Provider (ISP) or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices. This document analyzes the operational security issues associated with several types of networks and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise networks, service provider networks, or managed residential networks.', changed pages to 48, changed standardization level to Informational, changed state to RFC, added RFC published event at 2021-08-13, changed IESG state to RFC Published) |
|
2021-08-13
|
27 | (System) | RFC published |
|
2021-08-05
|
27 | (System) | RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9099">AUTH48-DONE</a> from AUTH48 |
|
2021-07-22
|
27 | (System) | RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9099">AUTH48</a> |
|
2021-06-07
|
27 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
|
2021-05-14
|
27 | (System) | RFC Editor state changed to EDIT |
|
2021-05-14
|
27 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2021-05-14
|
27 | (System) | Announcement was received by RFC Editor |
|
2021-05-14
|
27 | (System) | IANA Action state changed to No IANA Actions from In Progress |
|
2021-05-14
|
27 | (System) | IANA Action state changed to In Progress |
|
2021-05-14
|
27 | (System) | Removed all action holders (IESG state changed) |
|
2021-05-14
|
27 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2021-05-14
|
27 | Amy Vezza | IESG has approved the document |
|
2021-05-14
|
27 | Amy Vezza | Closed "Approve" ballot |
|
2021-05-14
|
27 | Amy Vezza | Ballot approval text was generated |
|
2021-05-14
|
27 | Amy Vezza | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
|
2021-05-07
|
27 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2021-05-07
|
27 | Chittimaneni Kk | New version available: draft-ietf-opsec-v6-27.txt |
|
2021-05-07
|
27 | (System) | New version approved |
|
2021-05-07
|
27 | (System) | Request for posting confirmation emailed to previous authors: Chittimaneni Kk <kk.chittimaneni@gmail.com>, Enno Rey <erey@ernw.de>, Eric Vyncke <evyncke@cisco.com>, Merike Kaeo … Request for posting confirmation emailed to previous authors: Chittimaneni Kk <kk.chittimaneni@gmail.com>, Enno Rey <erey@ernw.de>, Eric Vyncke <evyncke@cisco.com>, Merike Kaeo <merike@doubleshotsecurity.com> |
|
2021-05-07
|
27 | Chittimaneni Kk | Uploaded new revision |
|
2021-04-22
|
26 | (System) | Changed action holders to Merike Kaeo, Éric Vyncke, Chittimaneni Kk, Enno Rey (IESG state changed) |
|
2021-04-22
|
26 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation - Defer |
|
2021-04-22
|
26 | Tim Chown | Request for Telechat review by OPSDIR Completed: Ready. Reviewer: Tim Chown. Sent review to list. |
|
2021-04-22
|
26 | Robert Wilton | [Ballot comment] Hi, I would like to thank the authors for persevering with this document that has been in development for a long time. I … [Ballot comment] Hi, I would like to thank the authors for persevering with this document that has been in development for a long time. I was also like to thank Tim for his detailed OPSDIR reviews. I found the document informative to read, but in terms of the technical content, I don't have anything further to add beyond the other reviews comments. My overriding impression from reading this document (both due to the text and large number of references) is that deploying IPv6 seems to be very complex. I don't know how that complexity compares to v4 deployments. In several cases, this document alludes to different alternatives to how particular IPv6 features may be deployed, and the operational security considerations as they pertain to those choices. Not for this document, but it makes me wonder whether some useful future work in this area might be some BCP recommendations for how IPv6 should be deployed in particular types of networks .. although it is entirely possible that ship has already sailed, or there is too much variation on how v6 is being deployed to make such a recommendation. Regards, Rob |
|
2021-04-22
|
26 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
|
2021-04-22
|
26 | Murray Kucherawy | [Ballot comment] Thanks for this work. It's a useful document to have. I don't have much to add that my fellow ADs have not already … [Ballot comment] Thanks for this work. It's a useful document to have. I don't have much to add that my fellow ADs have not already mentioned. One procedural nit: The shepherd writeup lacks an answer to the question "Why is this the proper type of RFC?" (I realize "Informational" is the right answer here. I would just prefer it if shepherds answered it anyway.) It is also almost 18 months old. |
|
2021-04-22
|
26 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
|
2021-04-21
|
26 | Amanda Baber | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
|
2021-04-21
|
26 | Francesca Palombini | [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini |
|
2021-04-20
|
26 | Roman Danyliw | [Ballot comment] ** Section 2.1.5. Per “However, in scenarios where anonymity is a strong desire (protecting user privacy is more important than user attribution), privacy … [Ballot comment] ** Section 2.1.5. Per “However, in scenarios where anonymity is a strong desire (protecting user privacy is more important than user attribution), privacy extension addresses should be used.”, it might be worth acknowledging that even if these are managed network, the end user and the operators may be at odds on what privacy properties are important. ** Section 2.2.1. Per “A firewall or edge device should be used to enforce the recommended order and the maximum occurrences of extension headers”, does enforcement mean dropping the packets? ** Section 2.3.2. Per “Network operators should be aware that RA-Guard and SAVI do not work or could even be harmful in specific network configurations”, please provide a more details, ideally through citation. ** Section 2.3.2, “Enabling RA-Guard by default in … enterprise campus networks …”, what’s the key property of “enterprise campus network”. The introduction already roughly says this whole document applies to managed networks. ** Section 2.5.2. Reading this section, the specific recommended practices weren’t clear. ** Section 2.6. It wasn’t clear how comprehensive this list of logs was intended to be. A few additional thoughts include: -- DHCPv6 logs -- firewall ACL logs -- authentication server logs -- NEA-like policy enforcement at the time of connection -- vpn/remote access logs -- passive DNS from port 53 traffic -- full packet capture -- active network and service scanning/audit information ** Section 2.6.1.2. The recommended fields in this section are helpful, but only in the context of the rest of the five-tuple + timing + interface + vlan + select layer 4 information for each flow. These open IPFIX information elements aren't mentioned. ** Section 2.6.2.1. Per “The forensic use case is when the network operator must locate an IPv6 address that was present in the network at a certain time or is currently in the network”, isn’t this use case more precisely an attempt to link an IP address to (a) a specific port in the case of a wired network; (b) a access point (or base station, etc.) in the case of wireless; or (c) an external IP address in the case of a VPN connection? ** Section 2.6.2.1. Additional techniques/suggestions to consider: -- Using the IPAM system noted in Section 2.1 or any other inventory system to provide hints in the about where an IP address might belong in the topology. -- A reminder that mapping between and IP+port or MAC+IP might not have been the same one as during the time of the event of interest -- there is discussion about identifying subscribers for an ISP but not in normal enterprise network scenario through SSO logs (if port level security doesn’t exist) ** Section 2.6.2.2. Per “The first technique is to use the IPFIX information and extract the list of all IPv6 source addresses to find all of the IPv6 nodes that sent packets through the router”. This framing is mixing the technique with a particular logging format. I would recommend being clear that the technique is question is passive inspection of network talkers. There a several ways to get that: a properly configured IPFIX feed from a router, but also from any number of network analysis tools on a span port or a tap. ** Section 2.7.1. In addition to the two listed practices at the IPv4 edge, I would recommend adding the common practice of application specific flow inspection. ** Section 2.8. The intent of this section isn’t clear as all of the described practices are equally true of v4. A few missing hardening practices include: -- applying firmware, OS and application patches/upgrades to the devices in a timely manner. -- using multi-factor credentials to authenticate to devices ** Section 3. This section is titled “Enterprises Specific …”, how is an “enterprise” different than a “managed network” called out in the applicability statement? ** Section 3.1. This list is helpful. Is text here and Section 2.5.4 needed? For example, does one need to say both “discard _packets_ from bogons” (this section) and “discard _routes_ from bogons” (Section 2.5.4) |
|
2021-04-20
|
26 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
|
2021-04-19
|
26 | Benjamin Kaduk | [Ballot comment] While the guidance of the need to be prepared to postprocess logs to normalize the string representation of IPv6 addresses (if necessary) is … [Ballot comment] While the guidance of the need to be prepared to postprocess logs to normalize the string representation of IPv6 addresses (if necessary) is good, I am not sure that the specific perl code provided in Section 2.6.1.1 is useful to include. In addition to my specific comments in the section-by-section comments, it is in a sense a very blunt instrument that assumes whitespace-separated records and blindly tries to treat every word as an IPv6 address with no regard for the message/record format. This can easily induce collateral damage, and it seems that in most cases it will be possible to use a much more targeted normalization procedure that takes into account knowledge of the message structure. So my recommendation would be to just remove the specific example perl script. Section 2.1.1 Unique Local Addresses (ULAs) [RFC4193] are intended for scenarios where interfaces are not globally reachable, despite being routed within a domain. They formally have global scope, but [RFC4193] specifies that they must be filtered at domain boundaries. [...] I'm not seeing something quite so strong in RFC 4193. It has a note that "[i]f BGP is being used at the site border with an ISP, the default BDP configuration must filter out [...]", but that is only a default, and the guidance about non-BGP mechanisms is not even this strong. Section 2.1.2 Is there a reference for "the ping-pong attack" (where the use of the definite article implies there is a specific well-known attack)? Section 2.1.4 Stable addresses also allow easy enforcement of a security policy at the perimeter based on IPv6 addresses. [RFC8520] is a mechanism where the perimeter defense can retrieve security policy template based on the type of internal device. IIUC when using MUD there is a need to have a mapping from IP address to type of device (or MUD file), which doesn't seem to be mentioned by the text here. Section 2.1.7 Please call out the privacy considerations (already discussed in RFC 8273) of using a /64 per host. Section 2.2.3 If those requirements are not met, stateless filtering could be bypassed by a hostile party. [RFC6980] applies a stricter rule to Neighbor Discovery Protocol (NDP) by enforcing the drop of fragmented NDP packets. [...] As is clarified later in Section 2.3.2.1, fragmented Certification Path Advertisement messages are not required to be dropped. In my opinion we should provide a consistent treatment of the topic across all locations we mention it. Section 2.2.4 The IPsec [RFC4301] [RFC4301] extension headers (AH [RFC4302] and ESP [RFC4303]) are required if IPsec is to be utilized for network level security. But IPsec is no longer required for normal IPv6 nodes: in I think at this point AH is in practice deprecated, because ESP with NULL cipher can perform the same role. Also, is there any further commentary about IPsec in general that is appropriate for this document? Section 2.3.2.3 Isolating hosts for the NDP traffic can be done by using a /64 per host, refer to Section 2.1.7, as NDP is only relevant within a /64 on-link prefix; 3GPP Section 2.3.4 uses a similar mechanism. I recall some previous discussion about whether the prefix/IID boundary must fall at exactly 64 bits, but I trust the authors to have a better handle on this topic than I do. Section 2.6 Please note that there are privacy issues or regulations related to how these logs are collected, stored, and safely discarded. Also to how they are *used*, e.g., the "correlation" behavior listed below. Section 2.6.1.1 my (@words, $word, $binary_address) ; @words is unused. $binary_address = inet_pton AF_INET6, $word ; if ($binary_address) { print inet_ntop AF_INET6, $binary_address ; I'd strongly recommend using parentheses for at least the function calls inet_pton and inet_ntop. I also get warnings trying to run this code: Subroutine main::pack_sockaddr_in6 redefined at /usr/share/perl/5.26/Exporter.pm line 66. at ... line 5. Subroutine main::unpack_sockaddr_in6 redefined at /usr/share/perl/5.26/Exporter.pm line 66. at ... line 5. Subroutine main::sockaddr_in6 redefined at /usr/share/perl/5.26/Exporter.pm line 66. Section 2.6.1.4 This is an important source of information because it is trivial (on a switch not using the SAVI [RFC7039] algorithm) to defeat the mapping between data-link layer address and IPv6 address. Let us rephrase the previous statement: having access to the current and past content of the neighbor cache has a paramount value for the forensic and audit trail. And if it's interesting to the operator it's interesting to other parties as well; in certain threat models this information could itself be a target. Section 2.7.2 o reflection attack: another specific use case of tunnel injection where the attacker injects packets with an IPv4 destination address not matching the IPv6 address causing the first tunnel endpoint to re-encapsulate the packet to the destination... Hence, the final IPv4 destination will not see the original IPv4 address but only the IPv4 address of the relay router. Is it possible at least sometimes to configure the tunnel endpoints to drop traffic rather than "hairpin" it back out? To mitigate the bypassing of security policies, it is recommended to block all default configuration tunnels by denying IPv4 packets matching: [...] This is not something I'd expect in a general-purpose recommendation, so I wonder if a reminder (and backreference) of the Applicability Statement in Section 1.1 would help. o UDP protocol 3544: this will block the default encapsulation of Teredo (Section 2.7.2.8) tunnels. (really a nit, but up here since it's important) s/protocol/port/. Section 2.7.2.2 Special care must be taken to avoid a looping attack by implementing the measures of [RFC6324] and [RFC6964]. I see a section 3.6 in RFC 6964 entitled "Loop Avoidance"; are we intending to refer to just that guidance or the entire document? (I could easily imagine that there are other parts of the document that have relevance for this topic, but did not read closely enough to attempt to make my own determination of that.) Section 2.7.2.3 While 6rd tunnels share the same encapsulation as 6to4 tunnels (Section 2.7.2.7), they are designed to be used within a single SP domain, in other words, they are deployed in a more constrained environment than 6to4 tunnels and have few security issues other than lack of confidentiality. [...] My current guess is that the "more constrained environment" is intended to refer to a restricted or restricted-access environment that is assumed to not have any potential for (e.g.) traffic injection. But if lack of confidentiality remains an issue, it seems that the risk of an attacker or compromised device on the path is considered in scope, so I'm not sure how injection and the other attacks would be impossible in that case. I think we need some more clarity on what this sentence is intended to say. Section 2.7.2.4 Organizations using MPLS in their core can also use 6PE [RFC4798] and 6VPE [RFC4659] to enable IPv6 access over MPLS. As 6PE and 6VPE are really similar to BGP/MPLS IP VPNs described in [RFC4364], the security properties of these networks are also similar to those described in [RFC4381]. They rely on: (RFC 4381 is, of course, an ISE doc, so we are in some sense endorsing its content by referencing it in this way.) LDPv6 itself does not induce new risks, see also [RFC7552]. Should we say which security considerations continue to apply (i.e., the LDPv4 ones)? Section 2.7.2.8 Internet. While host policies can be deployed to block Teredo in an IPv4-only network in order to avoid this firewall bypass, it would be enough to block all UDP outbound traffic at the IPv4 firewall if deemed possible (of course, at least port 53 should be left open for DNS traffic, port 123 for NTP, port 443 for QUIC, port 500 for IKE, port 3478 for STUN, i.e., filter judiciously). I find it hard to accept as useful a recommendation to "block all UDP outbound traffic if deemeed possible" followed by a necessarily incomplete list of exceptions. Perhaps it is enough to note that when outbound UDP is blocked, outbound Teredo is likewise blocked, and keep the list of common UDP services. Section 2.7.3.2 The Security Consideration sections of [RFC6146] and [RFC6147] list the comprehensive issues. A specific issue with the use of NAT64 is that it will interfere with most IPsec deployments unless UDP encapsulation is used. DNSSEC and DNS64 negatively interact, see section 3.1 of [RFC7050]. My reading of Section 3.1 of RFC 7050 is more about using DNSSEC to secure the discovery of Pref64::/n than about the negative interactions between DNSSEC and DNS64. The latter seems to be covered in the (already referenced) security considerations section of RFC 6147, though. I might say something stronger than just "negatively interact", too. Section 2.8 o Use cryptographically protected protocols for device management if possible (SCP, SNMPv3, SSH, TLS, etc.) Since these are already only guidelines, I would strike "if possible". Section 3.1 In light of RFC 2804, I wonder whether more of a disclaimer is appropriate when referencing RFC 3924 and otherwise discussing lawful intercept. o Filter specific extension headers by accepting only the required ones (permit list approach) such as ESP, AH (not forgetting the required transport layers: ICMP, TCP, UDP, ...), where possible at the edge and possibly inside the perimeter; see also [I-D.ietf-opsec-ipv6-eh-filtering] [This seems to be another place where general-purpose and managed-network-specific advice diverge, and reiteration of the applicability statement might be in order.] o Implement appropriate rate-limiters and control-plane policers Is there a reference to give guidance on what is "appropriate"? NITS Section 1 This document complements [RFC4942] by listing all security issues I'm always a little wary of "all" or "comprehensive" when covering security issues; it's hard to be sure that we really have captured everything. Section 2.1 A common question is whether companies should use Provider Independent (PI) vs. Provider Allocated (PA) space [RFC7381], but The terminology used in 7381 seems to be about requesting address space from a LIR/RIR/NIR vs using "Provider-Aggregated" address space, so just searching for the terms listed here doesn't find much useful discussion. Perhaps linking to specifically Section 2.6 thereof would help. Section 2.1.4 While in some environments obfuscating addresses could be considered an added benefit, it does not preclude enforcement of perimeter rules and that stable addresses follow some logical allocation scheme for ease of operation (as simplicity always helps security). This sentence might be a bit long for a paragraph. I'd suggest breaking after "enforcement of perimeter rules" and continuing with "It also does not preclude stable addresses from following [...]" (assuming I'm even parsing the current version correctly). Section 2.1.5 Historically, stateless address autoconfiguration (SLAAC) makes up the globally unique IPv6 address based on an automatically generated Is "makes up" accurate for something that was only historically the recommended practice but no longer is? Disabling SLAAC and privacy extension addresses can be done for most operating systems by sending RA messages with a hint to get addresses via DHCPv6 by setting the M-bit but also disabling SLAAC by resetting all A-bits in all prefix information options. [...] I think s/but/and/? However, in scenarios where anonymity is a strong desire (protecting user privacy is more important than user attribution), privacy extension addresses should be used. When [RFC8064] is available, the RFC 8064 is a "recommendation" (and seems to defer to RFC 7217 for the actual computation), so maybe we are concerned about the "mechanisms recommended by RFC 8064" being available? Section 2.2.1 A firewall or edge device should be used to enforce the recommended order and the maximum occurrences of extension headers. If it's only a recommended order, why do we want to strictly enforce it? ;) Section 2.3.1 o Using a /127 on point-to-point link per [RFC6164]. either "a point-to-point link" or "links" o Using link-local addresses only on links where there are only routers, see [RFC7404] Is the first "only" correct? Section 2.3.2.3 A more drastic technique to prevent all NDP attacks is based on isolation of all hosts with specific configurations. Hosts (i.e., all nodes that are not routers) are unable to send data-link layer I suggest starting the second sentence with something like "When this technique is used" or "In such a scenario", since (AFAICT) the statement is not true in the general case. Section 2.3.2.4 hosts. This recommendation also applies when DHCPv6 is used as RA messages are used to discover the default router(s) and for on-link comma after "is used". in Section 2.2.3. The generated log should also be analyzed to identify and act on violations. Network operators should be aware What generated log? This document does not have a prior mention of logging. Enabling RA-Guard by default in Wi-Fi networks or enterprise campus networks should be strongly considered unless specific use cases such as the presence of devices Homenet devices emitting router advertisements preclude this. spurious (first?) "devices". Section 2.3.3 Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described in [RFC8415], enables DHCP servers to pass configuration parameters such as IPv6 network addresses and other configuration information to IPv6 nodes such as a recursive DNS server. DHCP plays an important "such as a recursive DNS server" should come before "to IPv6 nodes". The two most common threats to DHCP clients come from malicious (a.k.a., rogue) or unintentionally misconfigured DHCP servers. A malicious DHCP server is established with the intent of providing I'd suggest a transition phrase, such as "in these scenarios", as the current phrasing could be misread as an authoritative statement of the only reason why one might maliciously set up a DHCP server. incorrect configuration information to the clients to cause a denial- of-service attack or to mount on path attack. While unintentional, a "an on-path attack". Section 2.3.5 [RFC7772], [RFC6775] (for specific wireless networks) discuss methods to rate-limit RAs and other ND messages on wireless networks in order to address this issue. s/,/and/? Section 2.4 [RFC6192] defines the router control plane and provides detailed guidance to secure it for IPv4 and IPv6 networks. This definition is repeated here for the reader's convenience. Please note that the There is some churn in the diff, added commas and a few removed words. If possible, it might be worth using some formatting to indicate that only the one paragraph is quoted. its input queue with more packets than it can process. The control plane processor is then unable to process valid control packets and the router can lose OSPF or BGP adjacencies which can cause a severe network disruption. Why do we privilege OSPF as the only IGP mentioned? (Also later on.) Section 2.4.2 o Drop packets destined to the routers except those belonging to protocols which are used (for example, permit TCP 22 and drop all others when only SSH is used); (Isn't NETCONF on port 22 as well, given its use of ssh as substrate?) Section 2.4.3 o processing of the hop-by-hop options header, new implementations follow section 4.3 of [RFC8200] where this processing is optional; comma splice. On some routers, not everything can be done by the specialized data plane hardware which requires some packets to be 'punted' to the It's nice that we pseudo-define "punted" but we've used the term earlier already. packet exceptions. The only protection for the RP is to rate-limit those packet exceptions that are forwarded to the RP, this means that some data plane packets will be dropped without an ICMP message sent to the source which may delay Path MTU discovery and cause drops. comma splice Section 2.5.2 [RFC7166] changes OSPFv3 reliance on IPsec by appending an authentication trailer to the end of the OSPFv3 packets; it does not I suggest "adds an authentication mechanism for OSPFv3 other than IPsec"; the phrasing about "reliance" is a bit surprising since (I assume) many sites run without any cryptographic protection at all. specifically authenticate the specific originator of an OSPFv3 Maybe the specifically/specific are redundant and one could be dropped? With all authentication mechanisms, operators should confirm that implementations can support re-keying mechanisms that do not cause outages. There have been instances where any re-keying causes BCP 107 might be a good reference here for re-keying concepts. outages and therefore, the tradeoff between utilizing this functionality needs to be weighed against the protection it provides. This phrasing seems to imply that even now there is a tradeoff to weigh between using cryptographic protection and risk of outage. I'd suggest rewording to use the past tense and qualify that it is only the scenarios where re-keying requires outage that has such a pronounced tradeoff. (To be clear, there is still a tradeoff for using any cryptographic protection, but that is more along the lines of "fail-safe vs fail-open".) Section 2.5.3 Many routing protocols support the use of cryptography to protect the routing updates, the use of this protection is recommended; [RFC8177] is a YANG data model key chains including the renewal. "YANG data model for key chains that includes re-keying functionality". Section 2.5.4 o Configure ingress route filters that validate route origin, prefix ownership, etc. through the use of various routing databases, e.g., [RADB]. There is additional work being done in this area to formally validate the origin ASs of BGP announcements in [RFC8210]. To what extent is this still "work being done" vs a realized result, protocol-wise? Section 2.6.1.3 o interfaces-state/interface/statistics from ietf- interfaces@2018-02-20.yang [RFC8343] which contains counters for interface . I can't tell if this sentence ended prematurely or not. Section 2.6.1.4 The neighbor cache of routers contains all mappings between IPv6 addresses and data-link layer addresses. There are multiple ways to I think we've also used the terms "physical layer", "link-layer address", and "MAC address" already as well. o using streaming telemetry or NETCONF [RFC6241] and [RFC8040] to collect the operational state of the neighbor cache; Since RFC 8040 is RESTCONF this line doesn't scan very well. Section 2.6.1.5 address, some being data-link layer address prepended with time information, or even an opaque number which is useless for operational security. Moreover, when the DUID is based on the data- I suggest "that requires correlation with another data source to be usable for operational security". Section 2.6.1.6 used by the user. This technique can be used notably for Wi-Fi networks with Wi-Fi Protected Address (WPA) or any other IEEE 802.1X [IEEE-802.1X] wired interface on an Ethernet switch. Wi-Fi networks are not 802.1X wired interfaces (last I checked), so s/other//. Section 2.6.2.1 a subscriber via the RADIUS log. Alternatively, the Forwarding Information Base of the CMTS or BNG indicates the CPE of the Please expand CMTS and BNG. Section 2.6.2.3 In order to do correlation in IPv6-related logs, it is advised to have all logs in a format with only canonical IPv6 addresses [RFC5952]. Then, the neighbor cache current (or historical) data set (We made this recommendation already earlier.) Section 2.7.2 There are many tunnels used for specific use cases. Except when protected by IPsec [RFC4301], all those tunnels have a couple of security issues as described in RFC 6169 [RFC6169]; s/couple/number/ o bypassing security policy: if a firewall or an IPS is on the path Expand IPS. Section 2.7.2.1 tunnel injection are still possible. Therefore, the use of IPsec [RFC4301] in transport mode and protecting the encapsulated IPv4 packets is recommended for those tunnels. Alternatively, IPsec in s/and protecting/to protect/ Section 2.7.2.4 o Hiding the IPv4 core, hence removing all attacks against P-routers; This is the only place we use the term "P-router", so we might just expand out the definition to avoid the jargon. Section 2.7.2.6 As MAP has a predictable IPv4 address and port mapping, the audit logs are easier to manage. Easier to manage than what? Section 2.7.2.8 Teredo is now hardly never used and no longer enabled by default in s/hardly never/hardly ever/ most environments, so, it is less of a threat, however, special consideration must be taken in case of devices with older or non- s/case of/cases when/ Section 3.1 o Filter internal-use IPv6 addresses at the perimeter this will also mitigate the vulnerabilities listed in [RFC7359] Some kind of punctuation (sentence break; semicolon) after "perimeter". o Implement ingress and egress anti-spoofing in the forwarding and control planes, see [RFC2827] and [RFC3704] Using a BCP 84 reference would also pick up the updates in RFC 8704. It is recommended to filter at Internet connection(s) packets having a source or destination address belonging to the site internal prefix(es); this should be done for ingress and egress traffic. Do we want to say "respectively" here? (Filtering any traffic with source or destination belonging to internal prefixes would seem to result in the site being an island, disconnected from the internet...) Section 5 Some residential users have less experience and knowledge about security or networking. [...] Less than who/what? |
|
2021-04-19
|
26 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
|
2021-04-14
|
26 | Erik Kline | [Ballot comment] I think there are still a few nits here and there ("non-legit"?), but I know they'll get cleaned up. Thanks! |
|
2021-04-14
|
26 | Erik Kline | Ballot comment text updated for Erik Kline |
|
2021-04-14
|
26 | Erik Kline | [Ballot comment] I think there are still a few nits here and there ("non-legit"?), but I know they'll get cleaned up. |
|
2021-04-14
|
26 | Erik Kline | [Ballot Position Update] Position for Erik Kline has been changed to No Objection from Discuss |
|
2021-04-13
|
26 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Tim Chown |
|
2021-04-13
|
26 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Tim Chown |
|
2021-04-09
|
26 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2021-04-09
|
26 | Enno Rey | New version available: draft-ietf-opsec-v6-26.txt |
|
2021-04-09
|
26 | (System) | New version approved |
|
2021-04-09
|
26 | (System) | Request for posting confirmation emailed to previous authors: Chittimaneni Kk <kk.chittimaneni@gmail.com>, Enno Rey <erey@ernw.de>, Eric Vyncke <evyncke@cisco.com>, Merike Kaeo … Request for posting confirmation emailed to previous authors: Chittimaneni Kk <kk.chittimaneni@gmail.com>, Enno Rey <erey@ernw.de>, Eric Vyncke <evyncke@cisco.com>, Merike Kaeo <merike@doubleshotsecurity.com> |
|
2021-04-09
|
26 | Enno Rey | Uploaded new revision |
|
2021-04-07
|
25 | Benjamin Kaduk | Telechat date has been changed to 2021-04-22 from 2021-04-08 |
|
2021-04-07
|
25 | Benjamin Kaduk | IESG state changed to IESG Evaluation - Defer from IESG Evaluation |
|
2021-04-07
|
25 | Zaheduzzaman Sarker | [Ballot comment] I found this document very informative and I learned quite a lot by reading this document (I must confess I haven't read the … [Ballot comment] I found this document very informative and I learned quite a lot by reading this document (I must confess I haven't read the long list of referenced documents :-)). I think the collected recommendations in one place will be very helpful. Some comments - * The abstract says - "The recommendations in this document are not applicable to residential user cases". However, later on in section 1.1 it says - "This covers Service Provider (SP), enterprise networks and some knowledgeable-home-user-managed residential network." Furthermore in section 5, it recommends configurations for residential users. May be I am not getting the distinction among residential user cases, managed residential network and residential users correct but I think further clarification is needed on what is written in thee abstract and what is in the rest of the document. * I noted that section 2.3.4 refers to 3GPP 4G terminologies while describing the case. If this section is not supposed to restricted to certain generations of 3GPP technologies then I would recommend to update the section with 5G terminologies as well. * In section 2.6 there is an ask for the network operators to log "of all applications using the network (including user space and kernel space) when available (for example web servers)". How realistic is this? I hardly see the web servers sharing logging files with network operators ( I would be happy to be corrected here ). I am also missing the discussion on -- if not available how much this affects the forensic research in the event of security incident and abnormal behavior. |
|
2021-04-07
|
25 | Zaheduzzaman Sarker | Ballot comment text updated for Zaheduzzaman Sarker |
|
2021-04-07
|
25 | Zaheduzzaman Sarker | [Ballot comment] I found this document very informative and I learned quite a lot by reading this document (I must confess I haven't read the … [Ballot comment] I found this document very informative and I learned quite a lot by reading this document (I must confess I haven't read the long list of referenced documents :-)). I think the collected recommendations in one place will be very helpful. Some comments - * The abstract says - "The recommendations in this document are not applicable to residential user cases". However, later on in section 1.1 it says - "This covers Service Provider (SP), enterprise networks and some knowledgeable-home-user-managed residential network." Furthermore in section 5, it recommends configurations for residential users. May be I am not getting the distinction among residential user cases, managed residential network and residential users correct but I think further clarification is needed on what is written in thee abstract and what is in the rest of the document. * I noted that section 2.3.4 refers to 3GPP 4G terminologies while describing the case. If this section is not supposed to restricted to certain generations of 3GPP technologies then I would recommend to update the section with 5G terminologies as well. * In section 2.6 there is an ask for the network operators to log "of all applications using the network (including user space and kernel space) when available (for example web servers)". How realistic is this? I hardly see the web servers sharing logging files with network operators ( I would be happy to be corrected here ). I am also missing the discussion on -- if not available how much this affects the forensic research in the event of security incident and abnormal behavior. |
|
2021-04-07
|
25 | Zaheduzzaman Sarker | [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker |
|
2021-04-07
|
25 | Tim Chown | Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Tim Chown. Sent review to list. |
|
2021-04-06
|
25 | Erik Kline | [Ballot discuss] [ section 2.1 ] * "may also force the use of NPTv6" seems like it draws some conclusions. Perhaps something like: … [Ballot discuss] [ section 2.1 ] * "may also force the use of NPTv6" seems like it draws some conclusions. Perhaps something like: "may also increase the perceived need for the use of NPTv6"? [ section 2.2 ] * "It must also be noted that there is no indication in the IPv6 packet as to whether the Next Protocol field points to an extension header or to a transport header." What is this trying to say? Is this about what 8200 calls the "Next Header" field? If so, the Next Header field indicates...the next header, and whether that's a transport header or not depends on its value. I guess I read this text as implying that the 8200 standard is somehow ambiguous about what NH means, but it's really not. It's just that NH does not always indicate a transport. [ section 2.3.2.4 ] * "Only trivial cases [...] should have RA-guard..." Only? This doesn't strike me as being obviously the best recommendation. Definitely in trivial cases it should be enabled, but surely it should also be enabled even in more complex cases, albeit ones where knowledgeable administrators can configure things appropriately (vis. the applicability statement in section 1.1)...maybe? |
|
2021-04-06
|
25 | Erik Kline | [Ballot comment] [ general ] * There are many uses of ellipses ("...") that probably could be tightened up (usually just removed might work). … [Ballot comment] [ general ] * There are many uses of ellipses ("...") that probably could be tightened up (usually just removed might work). [ section 2.1.1 ] * I think it never hurts to repeat the message that ULA /48s from the fd00::/8 space (L=1) MUST be generated with a pseudo-random algorithm, per RFC 4193 sections 3.2, 3.2.1, &c. [ section 2.1.4 ] * I think the opening sentence might clarify that it's talking about stable address assignment for nodes. On a one-pass reading, section 2.1.3 immediately preceding this is discussing router loopback addressing, so I found I had routers on the brain when I started 2.1.4. [ section 2.1.5 ] * Up to you, but 4941 has been superseded by 8981. [ section 2.1.6 ] * "(see Section 2.6.1.5)" -> I think the trailing ")" probably wants to be at the end of that sentence; if not, it does not quite make grammatical sense (to me). [ section 2.2.3 ] * s/ipv6/IPv6/g [ section 2.3.5 ] * As an addendum to the final paragraph, it might be noted that such filtering can inhibit mDNS (whether or not that's a desirable outcome). [ section 2.4 ] * "non-legit": perhaps a bit too casual? [ section 2.6.1.7 ] * "as currently collected as in" -> "as currently collected in", I suspect [ section 2.6.2.1 ] * There are other motivations for doing forensic analysis that simply investigating "malicious activity" (even if this is the most common motivation). As a concrete proposal, perhaps: "At the end of the process, the interface of the host originating, or the subscriber identity associated with, the activity in question has been determined." ...or something [ section 2.7.2 ] * "legit": perhaps a bit too casual? "legitimate"? Or perhaps just s/legit and//. [ section 2.7.2.8 ] * s/IPV4/IPv4/ * Consider port 123 NTP in your allowlist. :-) * "hardly never" -> "hardly ever" [ section 2.7.3.1 ] * Does this section belong in this document? It's all about IPv4, and not even particular to IPv4 in the presence of IPv6 -- just IPv4 in general. [ section 2.7.3.2 ] * "DNSSEC has an impact on DNS64" It might also be said that "DNS64 has an impact on DNSSEC", so perhaps "DNSSEC and DNS64 negatively interact"? [ section 4.3 ] * "and what the respective log retention" -> "and the respective log retention", I think |
|
2021-04-06
|
25 | Erik Kline | [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline |
|
2021-04-06
|
25 | Lars Eggert | [Ballot comment] Section 2.3.1, paragraph 6, comment: > o Tuning of NDP process (where supported). Tuning in which way? Section 2.7.2, paragraph 2, comment: … [Ballot comment] Section 2.3.1, paragraph 6, comment: > o Tuning of NDP process (where supported). Tuning in which way? Section 2.7.2, paragraph 2, comment: > There are many tunnels used for specific use cases. Except when > protected by IPsec [RFC4301], all those tunnels have a couple of > security issues as described in RFC 6169 [RFC6169]; IPsec is not the only security mechanism that will protect tunnels, most tunnel encryption mechanisms would. ------------------------------------------------------------------------------- All comments below are very minor change suggestions that you may choose to incorporate in some way (or ignore), as you see fit. There is no need to let me know what you did with these suggestions. Section 2.5.3, paragraph 4, nit: > Many routing protocols support the use of cryptography to protect the > routing updates, the use of this protection is recommended; [RFC8177] > is a YANG data model key chains including the renewal. > I can't parse the part after the semicolon. Section 2.6.2.2, paragraph 9, nit: Might also want to mention http://www.entropy-ip.com/ and similar tools. Section 2.2.3, paragraph 3, nit: - not contain the entire ipv6 header chain (including the transport- - ^^ + not contain the entire IPv6 header chain (including the transport- + ^^ Section 2.2.3, paragraph 4, nit: - contain the entire ipv6 header chain (including the transport- - ^^ + contain the entire IPv6 header chain (including the transport- + ^^ Section 2.2.4, paragraph 2, nit: - the updated IPv6 Nodes Requirement standard [RFC8504] IPsec is a + the updated IPv6 Nodes Requirement standard [RFC8504], IPsec is a + + Section 2.3, paragraph 2, nit: - operations such as discovering other nodes on the link, resolving + operations, such as discovering other nodes on the link, resolving + + Section 2.3, paragraph 2, nit: - secured, NDP is vulnerable to various attacks such as router/neighbor + secured, NDP is vulnerable to various attacks, such as router/neighbor + + Section 2.3, paragraph 2, nit: - documented in IPv6 ND Trust Models and Threats [RFC3756] and in Section 2.3.1, paragraph 2, nit: - Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial + The Neighbor Discovery Protocol (NDP) can be vulnerable to remote denial + ++++ Section 2.3.1, paragraph 6, nit: - o Using /127 on point-to-point link per [RFC6164]. + o Using a /127 on a point-to-point link, per [RFC6164]. + ++ ++ + Section 2.3.2.3, paragraph 2, nit: - on-link prefix; 3GPP Section 2.3.4 uses a similar mechanism. + on-link prefix; 3GPP (see Section 2.3.4) uses a similar mechanism. + +++++ + Section 2.3.3, paragraph 2, nit: - Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described - in [RFC8415], enables DHCP servers to pass configuration parameters - such as IPv6 network addresses and other configuration information to - IPv6 nodes such as a hostile recursive DNS server. DHCP plays an + The Dynamic Host Configuration Protocol for IPv6 (DHCPv6), as described + ++++ + in [RFC8415], enables DHCP servers to pass configuration parameters, + + + such as IPv6 network addresses and other configuration information, to + + + IPv6 nodes, such as a hostile recursive DNS server. DHCP plays an + + Section 2.3.3, paragraph 3, nit: - of-service attack or to mount on path attack. While unintentional, a - ^ + of-service attack or to mount an on-path attack. While unintentional, a + +++ ^ Section 2.3.4, paragraph 2, nit: - address. This implies there can only be an end host (the mobile - ^ + address. This implies there can only be one end host (the mobile + ^ + Section 2.3.4, paragraph 2, nit: - address built by the mobile host. The GGSN/PGW always provides an - ^^^^ + address generated by the mobile host. The GGSN/PGW always provides an + ^^^^^^ ++ Section 2.3.4, paragraph 4, nit: - link model, NDP on it and the address configuration details. In some - ------ + link model, NDP and the address configuration details. In some Section 2.5, paragraph 8, nit: - interface where it is required. + interfaces where it is required. + + Section 2.5.4, paragraph 2, nit: - pertain to edge route filtering vs internal route filtering. At a + pertain to edge route filtering vs. internal route filtering. At a + + Section 2.6.1.5, paragraph 2, nit: - clients. It is indeed quite similar to DHCP for IPv4 so it can be + clients. It is indeed quite similar to DHCP for IPv4, so it can be + + Section 2.6.1.5, paragraph 3, nit: - It is not so easy in the IPv6 networks because not all nodes will use - ---- + It is not so easy in IPv6 networks, because not all nodes will use + + Section 2.7.3.1, paragraph 2, nit: - Carrier-Grade NAT (CGN), also called NAT444 CGN or Large Scale NAT - ^^^ + Carrier-Grade NAT (CGN), also called NAT444 CGN, Large Scale NAT + ^ Section 4.3, paragraph 3, nit: - (e.g., his/her PPP session, physical line, or CPE MAC address). With - ^^^^ + (e.g., his/her PPP session, physical line, or CPE MAC address). In + ^^ |
|
2021-04-06
|
25 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert |
|
2021-04-05
|
25 | Alvaro Retana | [Ballot comment] (1) The applicability statement in §1.1 is confusing to me. a. The Abstract says that "this document are not applicable to residential user … [Ballot comment] (1) The applicability statement in §1.1 is confusing to me. a. The Abstract says that "this document are not applicable to residential user cases", but that seems not to be true because this section says that the contents do apply to "some knowledgeable-home-user-managed residential network[s]", and §5 is specific to residential users. b. "This applicability statement especially applies to Section 2.3 and Section 2.5.4." Those two sections represent a small part of the document; what about the rest? It makes sense to me for the applicability statement to cover most of the document. c. "For example, an exception to the generic recommendations of this document is when a residential or enterprise network is multi-homed." I'm not sure if this sentence is an example of the previous one (above) or if "for example" is out of place. (2) §5 mentions "early 2020" -- I assume that the statement is still true now. (3) It caught my attention that there's only one Normative Reference (besides rfc8200, of course). Why? What is special about the IPFIX registry? It seems that an argument could be made to the fact that to secure OSPFv3, for example, an understanding of the protocol is necessary. This argument could be extended to other protocols or mechanisms, including IPv6-specific technology: ND, the addressing architecture, etc. Consider the classification of the references in light of [1]. [1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ |
|
2021-04-05
|
25 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
|
2021-04-05
|
25 | Martin Duke | [Ballot comment] I haven't gone through the dozens of references to verify the claims about them, so I'm trusting the WG and ADs here... In … [Ballot comment] I haven't gone through the dozens of references to verify the claims about them, so I'm trusting the WG and ADs here... In Sec 2.3.2.4, RA-Guard and SAVI are recommended, but then in the same paragraph it says that "only trivial cases" should enable it by default. I can't reconcile these two statements. |
|
2021-04-05
|
25 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
|
2021-04-02
|
25 | Éric Vyncke | [Ballot comment] As I am an author... BTW, did you notice the publication date? |
|
2021-04-02
|
25 | Éric Vyncke | [Ballot Position Update] New position, Recuse, has been recorded for Éric Vyncke |
|
2021-04-01
|
25 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
|
2021-04-01
|
25 | Cindy Morgan | Placed on agenda for telechat - 2021-04-08 |
|
2021-04-01
|
25 | Warren Kumari | Ballot has been issued |
|
2021-04-01
|
25 | Warren Kumari | [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari |
|
2021-04-01
|
25 | Warren Kumari | Created "Approve" ballot |
|
2021-04-01
|
25 | Warren Kumari | IESG state changed to IESG Evaluation from Waiting for Writeup |
|
2021-04-01
|
25 | Warren Kumari | Ballot writeup was changed |
|
2021-04-01
|
25 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2021-04-01
|
25 | Éric Vyncke | New version available: draft-ietf-opsec-v6-25.txt |
|
2021-04-01
|
25 | (System) | New version accepted (logged-in submitter: Éric Vyncke) |
|
2021-04-01
|
25 | Éric Vyncke | Uploaded new revision |
|
2021-03-23
|
24 | Acee Lindem | Request for Last Call review by RTGDIR Completed: Has Nits. Reviewer: Acee Lindem. Sent review to list. |
|
2021-03-23
|
24 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2021-03-19
|
24 | (System) | IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed |
|
2021-03-19
|
24 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-opsec-v6-24, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-opsec-v6-24, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. If this assessment is not accurate, please respond as soon as possible. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
|
2021-03-07
|
24 | Min Ye | Request for Last Call review by RTGDIR is assigned to Acee Lindem |
|
2021-03-07
|
24 | Min Ye | Request for Last Call review by RTGDIR is assigned to Acee Lindem |
|
2021-03-05
|
24 | Alvaro Retana | Requested Last Call review by RTGDIR |
|
2021-03-05
|
24 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
|
2021-03-05
|
24 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
|
2021-03-02
|
24 | Cindy Morgan | The following Last Call announcement was sent out (ends 2021-03-23):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: Gyan Mishra <hayabusagsm@gmail.com … The following Last Call announcement was sent out (ends 2021-03-23):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: Gyan Mishra <hayabusagsm@gmail.com>, draft-ietf-opsec-v6@ietf.org, hayabusagsm@gmail.com, opsec-chairs@ietf.org, opsec@ietf.org, warren@kumari.net Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-opsec-v6-24.txt> (Operational Security Considerations for IPv6 Networks) to Informational RFC The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Operational Security Considerations for IPv6 Networks' <draft-ietf-opsec-v6-24.txt> as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2021-03-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Knowledge and experience on how to operate IPv4 securely is available: whether it is the Internet or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol, but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices. This document analyzes the operational security issues associated with several types of network and proposes technical and procedural mitigation techniques. This document is only applicable to managed networks, such as enterprise building networks. The recommendations in this document are not applicable to residential user cases, even in cases where a Service Provider may be managing the home gateway. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ No IPR declarations have been submitted directly on this I-D. |
|
2021-03-02
|
24 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
|
2021-03-02
|
24 | Cindy Morgan | Last call announcement was changed |
|
2021-03-02
|
24 | Cindy Morgan | Last call announcement was generated |
|
2021-03-02
|
24 | Warren Kumari | Last call was requested |
|
2021-03-02
|
24 | Warren Kumari | Second IETF LC - there have been >200 changes, and the last IETF LC was in 2019. |
|
2021-03-02
|
24 | (System) | Changed action holders to Warren Kumari (IESG state changed) |
|
2021-03-02
|
24 | Warren Kumari | IESG state changed to Last Call Requested from Waiting for Writeup |
|
2021-02-12
|
24 | Éric Vyncke | New version available: draft-ietf-opsec-v6-24.txt |
|
2021-02-12
|
24 | (System) | New version accepted (logged-in submitter: Éric Vyncke) |
|
2021-02-12
|
24 | Éric Vyncke | Uploaded new revision |
|
2021-02-09
|
23 | Éric Vyncke | New version available: draft-ietf-opsec-v6-23.txt |
|
2021-02-09
|
23 | (System) | New version accepted (logged-in submitter: Éric Vyncke) |
|
2021-02-09
|
23 | Éric Vyncke | Uploaded new revision |
|
2021-02-08
|
22 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
|
2021-02-08
|
22 | Éric Vyncke | New version available: draft-ietf-opsec-v6-22.txt |
|
2021-02-08
|
22 | (System) | New version accepted (logged-in submitter: Éric Vyncke) |
|
2021-02-08
|
22 | Éric Vyncke | Uploaded new revision |
|
2020-02-10
|
21 | Wesley Eddy | Closed request for Last Call review by TSVART with state 'Overtaken by Events' |
|
2019-12-06
|
21 | Tim Chown | Request for Last Call review by OPSDIR Completed: Not Ready. Reviewer: Tim Chown. Sent review to list. |
|
2019-12-03
|
21 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Acee Lindem. |
|
2019-12-02
|
21 | Erik Kline | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Erik Kline. Sent review to list. |
|
2019-12-02
|
21 | Linda Dunbar | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Linda Dunbar. Sent review to list. |
|
2019-12-02
|
21 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
|
2019-11-16
|
21 | Ted Lemon | Request for Early review by IOTDIR Completed: On the Right Track. Reviewer: Ted Lemon. Sent review to list. |
|
2019-11-16
|
21 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Acee Lindem |
|
2019-11-16
|
21 | Luc André Burdet | Request for Last Call review by RTGDIR is assigned to Acee Lindem |
|
2019-11-15
|
21 | Jean Mahoney | Request for Last Call review by GENART is assigned to Erik Kline |
|
2019-11-15
|
21 | Jean Mahoney | Request for Last Call review by GENART is assigned to Erik Kline |
|
2019-11-14
|
21 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
|
2019-11-14
|
21 | Amanda Baber | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-opsec-v6-21, which is currently in Last Call, and has the following comments: We … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-opsec-v6-21, which is currently in Last Call, and has the following comments: We understand that this document doesn't require any registry actions. While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object. If this assessment is not accurate, please respond as soon as possible. Thank you, Amanda Baber Lead IANA Services Specialist |
|
2019-11-14
|
21 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Linda Dunbar |
|
2019-11-14
|
21 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Linda Dunbar |
|
2019-11-14
|
21 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
|
2019-11-14
|
21 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Tim Chown |
|
2019-11-12
|
21 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Martin Stiemerling |
|
2019-11-12
|
21 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Martin Stiemerling |
|
2019-11-11
|
21 | Alvaro Retana | Requested Last Call review by RTGDIR |
|
2019-11-11
|
21 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
|
2019-11-11
|
21 | Amy Vezza | The following Last Call announcement was sent out (ends 2019-12-02):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: hayabusagsm@gmail.com, warren@kumari.net, … The following Last Call announcement was sent out (ends 2019-12-02):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: hayabusagsm@gmail.com, warren@kumari.net, draft-ietf-opsec-v6@ietf.org, opsec@ietf.org, opsec-chairs@ietf.org, Gyan Mishra <hayabusagsm@gmail.com> Reply-To: last-call@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-opsec-v6-21.txt> (Operational Security Considerations for IPv6 Networks) to Informational RFC The IESG has received a request from the Operational Security Capabilities for IP Network Infrastructure WG (opsec) to consider the following document: - 'Operational Security Considerations for IPv6 Networks' <draft-ietf-opsec-v6-21.txt> as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2019-12-02. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Knowledge and experience on how to operate IPv4 securely is available: whether it is the Internet or an enterprise internal network. However, IPv6 presents some new security challenges. RFC 4942 describes the security issues in the protocol but network managers also need a more practical, operations-minded document to enumerate advantages and/or disadvantages of certain choices. This document analyzes the operational security issues in several places of a network (enterprises, service providers and residential users) and proposes technical and procedural mitigations techniques. Some very specific places of a network such as the Internet of Things are not discussed in this document. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/ballot/ No IPR declarations have been submitted directly on this I-D. |
|
2019-11-11
|
21 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
|
2019-11-11
|
21 | Amy Vezza | Last call announcement was changed |
|
2019-11-09
|
21 | Warren Kumari | Last call was requested |
|
2019-11-09
|
21 | Warren Kumari | Ballot approval text was generated |
|
2019-11-09
|
21 | Warren Kumari | Ballot writeup was generated |
|
2019-11-09
|
21 | Warren Kumari | IESG state changed to Last Call Requested from Publication Requested |
|
2019-11-09
|
21 | Warren Kumari | Last call announcement was generated |
|
2019-11-09
|
21 | Warren Kumari | Changed consensus to Yes from Unknown |
|
2019-11-08
|
21 | Gyan Mishra | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Informational. It is indicated. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document was created to prepare Enterprises, Service Providers and Residential users for security challenges presented with IPv6 deployment by analyzing the operation security issues and proposing technical and procedural mitigation techniques. Operations security considerations are covered in great detail in this document from creating an IPv6 addressing architecture that allows for easily crafted infrastructure access lists to first hop router security, control plane security, securing routing protocols, to external perimeter security best practices guidelines for IPv6 deployments. Working Group Summary A number of members in the working group other then the authors expressed support and contributed providing positive feedback to the document and are all listed in the acknowledgement section. We have working group consensus to publish the document. Nobody is against publishing the document. Document Quality The authors Eric Vyncke, Kiran Chittimaneni, Merike Kaeo, Enno Rey and the Shepherd carefully reviewed the document and provided a number of comments and ensured the document quality. Personnel Shepherd is Gyan Mishra. AD is Warren Kumari. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The Shepherd believes the document is ready for publication. AD Warren Kumari identified some grammatical editorial corrections which were made after the Shepherd’s review and was updated in version-21. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No Concern. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. All authors have confirmed that they are not aware of any IPR. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosure has been filed. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? All WG member apart from the authors are supporting this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No (11) Identify any ID nits the Document Shepherd has found in this document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Ran idnits 2.16.02 and informational reference check found obsolete reference RFC 2460 (Obsoleted by RFC 8200), obsolete reference RFC 3068 (Obsoleted by RFC 7526), and obsolete reference RFC 3627 (Obsoleted by RFC 6547) (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review needed. (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126). This document includes no request for IANA. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. No new registries. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. N/A |
|
2019-11-03
|
21 | Chittimaneni Kk | New version available: draft-ietf-opsec-v6-21.txt |
|
2019-11-03
|
21 | (System) | New version approved |
|
2019-11-03
|
21 | (System) | Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk … Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk <kk.chittimaneni@gmail.com> |
|
2019-11-03
|
21 | Chittimaneni Kk | Uploaded new revision |
|
2019-10-29
|
20 | Samita Chakrabarti | Request for Early review by IOTDIR is assigned to Ted Lemon |
|
2019-10-29
|
20 | Samita Chakrabarti | Request for Early review by IOTDIR is assigned to Ted Lemon |
|
2019-10-28
|
20 | Éric Vyncke | Requested Early review by IOTDIR |
|
2019-10-15
|
20 | Ron Bonica | Responsible AD changed to Warren Kumari |
|
2019-10-15
|
20 | Ron Bonica | IETF WG state changed to Submitted to IESG for Publication from In WG Last Call |
|
2019-10-15
|
20 | Ron Bonica | IESG state changed to Publication Requested from I-D Exists |
|
2019-10-15
|
20 | Ron Bonica | IESG process started in state Publication Requested |
|
2019-10-15
|
20 | Ron Bonica | Notification list changed to Gyan Mishra <hayabusagsm@gmail.com> |
|
2019-10-15
|
20 | Ron Bonica | Document shepherd changed to Gyan Mishra |
|
2019-10-12
|
20 | Éric Vyncke | New version available: draft-ietf-opsec-v6-20.txt |
|
2019-10-12
|
20 | (System) | New version accepted (logged-in submitter: Éric Vyncke) |
|
2019-10-12
|
20 | Éric Vyncke | Uploaded new revision |
|
2019-09-23
|
19 | Jen Linkova | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
|
2019-09-23
|
19 | Jen Linkova | IETF WG state changed to In WG Last Call from WG Document |
|
2019-09-22
|
19 | Éric Vyncke | New version available: draft-ietf-opsec-v6-19.txt |
|
2019-09-22
|
19 | (System) | New version approved |
|
2019-09-22
|
19 | (System) | Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk … Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk <kk.chittimaneni@gmail.com> |
|
2019-09-22
|
19 | Éric Vyncke | Uploaded new revision |
|
2019-09-21
|
18 | Éric Vyncke | New version available: draft-ietf-opsec-v6-18.txt |
|
2019-09-21
|
18 | (System) | New version approved |
|
2019-09-21
|
18 | (System) | Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk … Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk <kk.chittimaneni@gmail.com> |
|
2019-09-21
|
18 | Éric Vyncke | Uploaded new revision |
|
2019-07-05
|
17 | Enno Rey | New version available: draft-ietf-opsec-v6-17.txt |
|
2019-07-05
|
17 | (System) | New version approved |
|
2019-07-05
|
17 | (System) | Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk … Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk <kk.chittimaneni@gmail.com> |
|
2019-07-05
|
17 | Enno Rey | Uploaded new revision |
|
2019-03-11
|
16 | Éric Vyncke | New version available: draft-ietf-opsec-v6-16.txt |
|
2019-03-11
|
16 | (System) | New version approved |
|
2019-03-11
|
16 | (System) | Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk … Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk <kk.chittimaneni@gmail.com> |
|
2019-03-11
|
16 | Éric Vyncke | Uploaded new revision |
|
2019-03-09
|
15 | Éric Vyncke | New version available: draft-ietf-opsec-v6-15.txt |
|
2019-03-09
|
15 | (System) | New version approved |
|
2019-03-09
|
15 | (System) | Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk … Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com>, Chittimaneni Kk <kk.chittimaneni@gmail.com> |
|
2019-03-09
|
15 | Éric Vyncke | Uploaded new revision |
|
2018-10-22
|
14 | Éric Vyncke | New version available: draft-ietf-opsec-v6-14.txt |
|
2018-10-22
|
14 | (System) | New version approved |
|
2018-10-22
|
14 | (System) | Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Kiran Chittimaneni <kk@dropbox.com>, Merike Kaeo <merike@doubleshotsecurity.com>, opsec-chairs@ietf.org, … Request for posting confirmation emailed to previous authors: Enno Rey <erey@ernw.de>, Kiran Chittimaneni <kk@dropbox.com>, Merike Kaeo <merike@doubleshotsecurity.com>, opsec-chairs@ietf.org, Eric Vyncke <evyncke@cisco.com> |
|
2018-10-22
|
14 | Éric Vyncke | Uploaded new revision |
|
2018-09-02
|
13 | (System) | Document has expired |
|
2018-07-02
|
13 | Tim Chown | Request for Early review by OPSDIR Completed: Not Ready. Reviewer: Tim Chown. Sent review to list. |
|
2018-03-26
|
13 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Tim Chown |
|
2018-03-26
|
13 | Gunter Van de Velde | Request for Early review by OPSDIR is assigned to Tim Chown |
|
2018-03-26
|
13 | Gunter Van de Velde | Requested Early review by OPSDIR |
|
2018-03-21
|
13 | Éric Vyncke | Added to session: IETF-101: opsec Wed-1520 |
|
2018-03-01
|
13 | Éric Vyncke | New version available: draft-ietf-opsec-v6-13.txt |
|
2018-03-01
|
13 | (System) | New version approved |
|
2018-03-01
|
13 | (System) | Request for posting confirmation emailed to previous authors: Kiran Chittimaneni <kk@dropbox.com>, Merike Kaeo <merike@doubleshotsecurity.com>, opsec-chairs@ietf.org, Eric Vyncke <evyncke@cisco.com> |
|
2018-03-01
|
13 | Éric Vyncke | Uploaded new revision |
|
2017-10-30
|
12 | Éric Vyncke | New version available: draft-ietf-opsec-v6-12.txt |
|
2017-10-30
|
12 | (System) | New version approved |
|
2017-10-30
|
12 | (System) | Request for posting confirmation emailed to previous authors: Kiran Chittimaneni <kk@dropbox.com>, Merike Kaeo <merike@doubleshotsecurity.com>, Eric Vyncke <evyncke@cisco.com> |
|
2017-10-30
|
12 | Éric Vyncke | Uploaded new revision |
|
2017-10-13
|
11 | (System) | Document has expired |
|
2017-09-29
|
11 | Gunter Van de Velde | Update of the document was suggested by authors during IETF99 OPSEC WG meeting. Waiting for Update. |
|
2017-09-29
|
11 | Gunter Van de Velde | Tag Revised I-D Needed - Issue raised by WGLC set. |
|
2017-09-29
|
11 | Gunter Van de Velde | IETF WG state changed to WG Document from In WG Last Call |
|
2017-07-18
|
11 | Éric Vyncke | Added to session: IETF-99: opsec Wed-1330 |
|
2017-04-12
|
11 | Gunter Van de Velde | WG last call running for 2 weeks and expected to end on 26 April is initiated on 12 April 2017 |
|
2017-04-12
|
11 | Gunter Van de Velde | IETF WG state changed to In WG Last Call from WG Document |
|
2017-04-12
|
11 | Gunter Van de Velde | Intended Status changed to Informational from None |
|
2017-04-11
|
11 | Éric Vyncke | New version available: draft-ietf-opsec-v6-11.txt |
|
2017-04-11
|
11 | (System) | New version approved |
|
2017-04-11
|
11 | (System) | Request for posting confirmation emailed to previous authors: Kiran Chittimaneni <kk@dropbox.com>, Merike Kaeo <merike@doubleshotsecurity.com>, opsec-chairs@ietf.org, Eric Vyncke <evyncke@cisco.com> |
|
2017-04-11
|
11 | Éric Vyncke | Uploaded new revision |
|
2017-03-13
|
10 | Éric Vyncke | New version available: draft-ietf-opsec-v6-10.txt |
|
2017-03-13
|
10 | (System) | New version approved |
|
2017-03-13
|
10 | (System) | Request for posting confirmation emailed to previous authors: Kiran Chittimaneni <kk@dropbox.com>, Merike Kaeo <merike@doubleshotsecurity.com>, opsec-chairs@ietf.org, Eric Vyncke <evyncke@cisco.com> |
|
2017-03-13
|
10 | Éric Vyncke | Uploaded new revision |
|
2017-01-08
|
09 | (System) | Document has expired |
|
2016-07-07
|
09 | Éric Vyncke | New version available: draft-ietf-opsec-v6-09.txt |
|
2016-03-21
|
08 | Éric Vyncke | New version available: draft-ietf-opsec-v6-08.txt |
|
2015-09-09
|
07 | Éric Vyncke | New version available: draft-ietf-opsec-v6-07.txt |
|
2015-03-09
|
06 | Éric Vyncke | New version available: draft-ietf-opsec-v6-06.txt |
|
2014-10-27
|
05 | Éric Vyncke | New version available: draft-ietf-opsec-v6-05.txt |
|
2013-10-21
|
04 | Chittimaneni Kk | New version available: draft-ietf-opsec-v6-04.txt |
|
2013-07-15
|
03 | Éric Vyncke | New version available: draft-ietf-opsec-v6-03.txt |
|
2013-02-24
|
02 | Chittimaneni Kk | New version available: draft-ietf-opsec-v6-02.txt |
|
2012-11-08
|
01 | Chittimaneni Kk | New version available: draft-ietf-opsec-v6-01.txt |
|
2012-09-21
|
00 | Merike Kaeo | New version available: draft-ietf-opsec-v6-00.txt |