Heho,
On Fri, 2017-05-05 at 18:54 -0700, Merike Kaeo wrote:
> Just as Ack re capturing all the comments and discusisons and working
> with other co-authors to resolve.
>
> If anyone is at RIPE meeting and would like to discuss, let me know.
As discussed at the last IETF I gave -11 of the document a review an
have some comments. Please find an inline-commented version attached.
With best Regards,
Tobias
--
Tobias Fiebig building MAR, 4th floor, room 4.003
Fachgebiet INET - Sekr. MAR 4-4 phone: +49 162 243 205 2
Technische Universität Berlin gpg-fp: 21A9 91EB 4971 ED48 001E
Marchstrasse 23 - 10587 Berlin FBBC B6AF 3CD8 59A2 795B
2. Generic Security Considerations
2.1. Addressing Architecture
...
A common question is whether companies should use PI vs PA space
[RFC7381], but from a security perspective there is little
difference. However, one aspect to keep in mind is who has
administrative ownership of the address space and who is technically
responsible if/when there is a need to enforce restrictions on
routability of the space due to malicious criminal activity.
# it should be kept in mind here, that PA space can incur renumbering on a
# provider change. Following the first paragraph, the ensuing change also drags
# in changes to ACLs etc, where things can go wrong. Contrary to the first
# par, however, this can not be prevented by a more stringend addressing
# approach from the start.
2.1.1. Statically Configured Addresses
...
While in some environments the security is so poor that obfuscating
addresses is considered a benefit; it is a better practice to ensure
that perimeter rules are actively checked and enforced and that
statically configured addresses follow some logical allocation scheme
for ease of operation.
# I am rather uncomfortable with 2.1.1; The first paragraph nearly sounds like
# a recommendation of security by obscurity. While the second par. refutes this,
# i would personally prefer a stronger statement against sec. by obscurity
# here.
2.1.4. Temporary Addresses - Privacy Extensions for SLAAC
...
As privacy extension addresses could also be used to obfuscate some
malevolent activities (whether on purpose or not), it is advised in
scenarios where user attribution is important to rely on a layer-2
authentication mechanism such as IEEE 802.1X [IEEE-802.1X] with the
appropriate RADIUS accounting (Section 2.6.1.6) or to disable SLAAC
and rely only on DHCPv6. However, in scenarios where anonymity is a
strong desire (protecting user privacy is more important than user
attribution), privacy extension addresses should be used.
# I am not certain about this paragraph. I see no operational disadvantage
# of using priv. ext. in any case. This paragraph sounds like it is ok to
# not use 802.1X in cases where one needs strict user attribution, as long as
# priv. ext. are not used. However, this suggestion is a forensic nightmare.
# Even if a client (over which one not necessarily holds control, is not using/
# is forced to not use priv extensions, it might still use other addresses,
# which it should not use. As long as there is no 802.1X with appr. accounting,
# there is no way to conclusively tell. Hence, I'd like to see a stronger
# statement for 802.1X/radius in cases where attribution is necessary.
Using privacy extension addresses prevents the operator from building
a priori host specific access control lists (ACLs). It must be noted
that recent versions of Windows do not use the MAC address anymore to
build the stable address but use a mechanism similar to the one
described in [RFC7217], this also means that such an ACL cannot be
configured based solely on the MAC address of the nodes, diminishing
the value of such ACL. On the other hand, different VLANs are often
used to segregate users, in this case ACL can rely on a /64 prefix
per VLAN rather than a per host ACL entry.
# This is a good point. However, at this point it might also be good to
# indicate that (in addition to ACLs) user-bound authentication in addition to
# acl based (device) authentication may be useful.
The decision to utilize privacy extension addresses can come down to
whether the network is managed versus unmanaged. In some
environments full visibility into the network is required at all
times which requires that all traffic be attributable to where it is
sourced or where it is destined to within a specific network. This
situation is dependent on what level of logging is performed. If
logging considerations include utilizing accurate timestamps and
logging a node's source ports [RFC6302] then there should always
exist appropriate user attribution needed to get to the source of any
malware originator or source of criminal activity.
# yes, but this statement basically encourages a full-fledged logging for the
# usecase of "find malware". However, this feels like the "standard" use-case
# for an ISP's access network. (I see that there usually radius/per-user (/48
# or /64)s). Still, this sounds like a good way to use malware-protection as a
# pretense to deploy full-scale user-action logging, which is currently
# commonly discussed in various nation states.
Disabling SLAAC and privacy extensions addresses can be done by
sending Router Advertisement 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 sent in the Router Advertisement
message.
# However, as i understand it, the clients do not have to adhere, especially
# considering an unmanaged network, doe they?
...
2.2. Extension Headers
The extension headers are one of the most critical differentiator
between IPv4 and IPv6. They have also become a very controversial
topic since forwarding nodes that discard packets containing
extension headers are known to cause connectivity failures and
deployment problems. Understanding the role of varying extension
headers is important and this section enumerates the ones that need
careful consideration. The IANA has closed the the existing empty
# double the
2.3.2. Securing DHCP
...
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
incorrect configuration information to the client to cause a denial
of service attack or mount a man in the middle attack. While
unintentionall, a misconfigured DHCP server can have the same impact.
Additional threats against DHCP are discussed in the security
considerations section of RFC3315 [RFC3315]DHCP-shield
# line breaking feels not right in the .txt version here
RFC7610 [RFC7610] specifies a mechanism for protecting connected
DHCPv6 clients against rogue DHCPv6 servers. This mechanism is based
on DHCPv6 packet-filtering at the layer-2 device; the administrator
specifies the interfaces connected to DHCPv6 servers.
It is recommended to use DHCP-shield.
# practical experience from the Chaos Communication Congress network also
# indicates that it is beneficial to actually do logging/monitoring of
# those -> i.e. implement a process to actively approach these systems.
2.3.4. ND/RA Filtering
...
It is still recommended that RA-Guard be be employed as a first line
of defense against common attack vectors including misconfigured
hosts.
# As before with rDHCP, we had quiet some success with specifically monitoring
# for RA with a state-capable monitoring system.
...
2.6. Logging/Monitoring
In order to perform forensic research in case of any security
incident or to detect abnormal behaviors, network operator should log
# network operators
multiple pieces of information.
...
o forensic (Section 2.6.2.1) research to answer questions such as
# I would word this as "forensic (Section 2.6.2.1) investigations to..."
who did what and when?
...
2.6.1.1. Logs of Applications
# it is important to note that reverse DNS is frequently used by applications
# to translate an address to a readable form. However, a possible attacker has
# commonly control over the rdns of the remote system. Hence, she could enter
# an unsuspicious name there, which might be later used in the logs.
# In fact, wtmp is a common example of this happening:
# tfiebig@gallifrey ~ % last
# ******** pts/14 hsi-kbw-***-***- Sat May 6 19:57 still logged in
# ******** pts/14 hsi-kbw-***-***- Sat May 6 18:17 - 19:57 (01:39)
# hence, a recommendation to ensure that at least the address is logged as well
# might be good.
...
2.6.2.1. Forensic
...
At the end of the process, the interface where the malicious user was
connected or the username that was used by the malicious user is
found.
# I do not like this formulation, as it follows a common falicy in forensics,
# assuming that identifying a host/uid already reveales the culprit.
# I would prefer a more neutral formulation: At the end of the proccess, the
# interface to which the host originating malicious activity or the username
# which was abused for malicious activity has been determined.
2.6.2.2. Inventory
...
Other techniques involve enumerating the DNS zones, parsing log
files, leveraging service discovery such as mDNS RFC6762 [RFC6762]
and RFC6763 [RFC6763].
Other techniques involve enumerating the DNS zones, especially
looking at reverse DNS records and CNAMES. Or scanning for DNS
misconfigurations to find DNS servers that send NXDOMAIN instead of
NOERROR for non-existing nodes with children, which violates RFC8020
[RFC8020]. Parsing log files and leveraging service discovery such
as mDNS RFC6762 [RFC6762] and RFC6763 [RFC6763] are also added
techniques.
# The last to paragraphs feel somewhat redundant. Furthermore, the description
in par2
# of the NXD technique is not fully accurate. In fact, only those that do
violate
# RFC8020 can _NOT_ be enumerated. I would structure it like
# this:
# Other techniques involve obtaining data from DNS, parsing log files,
# leveraging service discovery such as mDNS RFC6762 [RFC6762] and
# RFC6763 [RFC6763].
#
# Enumerating DNS zones, especially looking at reverse DNS records and CNAMES,
# can be done by exploiting RFC8020 [RFC8020]. As already metioned in
# RFC7707 [RFC7707], this allows an attacker to prune the IPv6 reverse DNS tree,
# and hence enumerate it in a feasible time. Furthermore, authoritative
# servers that allow zone transfers (AXFR) may be a further information source.
2.6.2.3. Correlation
...
In an IPv6 network, this is slightly more difficult because different
character strings can express the same IPv6 address. Therefore, the
simple Unix grep command cannot be used. Moreover, an IPv6 node can
have multiple IPv6 addresses...
# This feels like to many dots.
...
2.7. Transition/Coexistence Technologies
Some text
# here you could mention sth. i just recently observed in practice. Considering
# reverse DNS, this gets broken in a NAT64/DNS64 setup.
# Still, this is commonly used to obtian further information, especially in
# middleboxes, for remote hosts.
# To the best of my
# knowledge, there is no clear transition technology defined in the DNS64
# RFC that preserves reverse DNS for the remote hosts in a NAT64 setup.
# However, i recently found an ISP in the APNIC region, which mapps in-addr.arpa
# into its nat64 prefix's ip6.arpa. zone.
2.7.1. Dual Stack
Dual stack has established itself as the preferred deployment choice
for most network operators without an MPLS core where 6PE RFC4798
[RFC4798] is quite common. Dual stacking the network offers many
advantages over other transition mechanisms. Firstly, it is easy to
turn on without impacting normal IPv4 operations. Secondly, perhaps
more importantly, it is easier to troubleshoot when things break.
Dual stack allows you to gradually turn IPv4 operations down when
your IPv6 network is ready for prime time.
# something which should be addresses in this section as well is the threat
# of introducing IPv6 via RA/DHCPv6 in a dual-stack setting to systems.
# Systems that are not "prepared" to be fully exposed on the internet
# may receive an address this way, which puts them into harms way.
...
2.7.2. Transition Mechanisms
# with the observed decline in transition technique's use (e.g. google/akamai
# ipv6 reports) i am not so sure if this should take so much space. Still,
# what holds is that even though they are not actively used anymore, most of
# these techniques continue to be available (to attackers). On second thought,
# maybe this should be mentionend specifically.
...
2.7.2.1. Site-to-Site Static Tunnels
Site-to-site static tunnels are described in RFC 2529 [RFC2529] and
in GRE [RFC2784]. As the IPv4 endpoints are statically configured
and are not dynamic they are slightly more secure (bi-directional
service theft is mostly impossible) but traffic interception ad
# intercetption and
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
tunnel mode can be used to transport IPv6 traffic over a non-trusted
IPv4 network.
...
2.7.2.3. Teredo
...
The biggest threat to Teredo is probably for IPv4-only network as
Teredo has been designed to easily traverse IPV4 NAT-PT devices which
are quite often co-located with a stateful firewall. Therefore, if
the stateful IPv4 firewall allows unrestricted UDP outbound and
accept the return UDP traffic, then Teredo actually punches a hole in
this firewall for all IPv6 traffic to the Internet and from the
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
more efficient 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).
# hrm, depends. This could also be solved by a DMZ host that acts as local
# resolver.
...
2.7.3.2. NAT64/DNS64
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. DNS64 has an incidence on DNSSEC see section
3.1 of [RFC7050].
# there is another NAT64/DNS64 comment from me furhter down about reverse DNS
# consistency. Maybe this might fit here as well.
...
3. Enterprises Specific Security Considerations
# I am not sure, that this section is actually so enterprise specific. The
# recommendations given in this section feel more like something which should
# be in place everywhere.
...
5. Residential Users Security Considerations
...
If the Residential Gateway has IPv6 connectivity, [RFC7084] (which
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]:
o outbound only: allowing all internally initiated connections and
block all externally initiated ones, which is a common default
security policy enforced by IPv4 Residential Gateway doing NAT-PT
but it also breaks the end-to-end reachability promise of IPv6.
[RFC6092] lists several recommendations to design such a CPE;
o open/transparent: allowing all internally and externally initiated
connections, therefore restoring the end-to-end nature of the
Internet for the IPv6 traffic but having a different security
policy for IPv6 than for IPv4.
[RFC6092] REC-49 states that a choice must be given to the user to
select one of those two policies.
There is also an alternate solution which has been deployed notably
by Swisscom ([I-D.ietf-v6ops-balanced-ipv6-security]: open to all
outbound and inbound connections at the exception of an handful of
TCP and UDP ports known as vulnerable.
# I would really appreciate a stand here. The problem scetched is indeed
# similar to the "hosts suddenly get an IPv6 address via DHCPv6 I mentioned
# before. I would really like to see a specific claim for secure defaults
# here, which does not violate RFC6204/RFC6092: Suggest that CPEs are
# delivered with default-outbound-only, but MUST leave the user an option
# to change this. This is basically to protect the new IoT fridges in 99.99%
# of the homes which will never bother to change whatever default is set.
_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec
