Re: [OPSEC] Asking for a review of draft-ietf-opsec-v6-08

["Fred Baker (fred)" <[e-mail]>]

One thing I wondered about as reading this - many and perhaps most sections gave a fairly informative comment, and then made one or two recommendations. I wonder (this is a question) whether it would be worthwhile capitalizing "RECOMMEND", both in the sense of defining the term (RFC 2119) and highlighting it in the text. I also wonder if it would make sense to pull together a list of recommendations made in a table somewhere, perhaps in an appendix. I could imagine someone wanting a list of them without wading through the text.

> 1.  Introduction
> 
>    Running an IPv6 network is new for most operators not only because
>    they are not yet used to large scale IPv6 networks but also because
>    there are subtle differences between IPv4 and IPv6 especially with
>    respect to security.  For example, all layer-2 interactions are now
>    done by Neighbor Discovery Protocol [RFC4861] rather than by Address

s/by/using/, twice. As worded, it sounds like NDP and ARP doing this by themselves, as *actors*; no, the *system* does them using NDP and ARP as its *language*.

>    Resolution Protocol [RFC0826].  Also, there are subtle differences
>    between NAT44 and NPTv6 [RFC6296] which are explicitly pointed out in
>    the latter's security considerations section.

For NAT44, I might also point to RFC 2993 and maybe 4864.

>    IPv6 networks are deployed using a variety of techniques, each of
>    which have their own specific security concerns.


> 2.  Generic Security Considerations
> 
> 2.1.  Addressing Architecture
> 
>    IPv6 address allocations and overall architecture are an important
>    part of securing IPv6.  Typically what you initially design for will
>    be what you use for a very long time.

This sentence is in the second person ("you"), and most of the document is third person ("it"). Reword as "Initial designs, even if intended to be temporary, tend to last much longer than expected"?

> Although initially IPv6 was
>    thought to make renumbering easy, in practice, it would be extremely
>    difficult to renumber.

I would temper the statement. As we said in RFC 4192, the problems with renumbering tends to be the places where a number is written into a static configuration rather than managed using a database or whatever, and the places where people cut corners ("its address will never change, so I don't need to worry about its name and DNS"). I would find myself saying that good OSS trumps static configurations, and in IPv6, systems change at least their IIDs from time to time (RFC 7721). It's not that IPv6 (or IPv4) is hard to renumber, it's that the required operational support is often not there or not workable due to poor practice.

>    Once an address allocation has been assigned, there should be some
>    thought given to an overall address allocation plan.  With the
>    abundance of address space available, an address allocation may be
>    structured around services along with geographic locations, which

"topology"? Topology is often structured geographically, yes, but if A provides services to B and C and is a logical gateway to them, A, B, and C can be grouped for management purposes even if they are not in the same geographic location.

>    then can be a basis for more structured security policies to permit
>    or deny services between geographic regions.
> 
>    A common question is whether companies should use PI vs PA space
>    [RFC7381] but from a security perspective there is little difference.

comma after "[RFC7381]".

>    However, one aspect to keep in mind is who has ownership of the
>    address space and who is responsible if/when Law Enforcement may need
>    to enforce restrictions on routability of the space due to malicious
>    criminal activity.

Pregnant statement. I find myself wondering about the implications of "ownership" and "law enforcement restrictions on routability". In "ownership", are you pointing to issues when you change providers and therefore need to change PA addresses? If not, something else? In "LEA issues", are you talking about law enforcement blocking the address space, turning BGP announcements off, etc?



> 2.1.1.  Statically Configured Addresses
> 
>    When considering how to assign statically configured addresses it is
>    necessary to take into consideration the effectiveness of perimeter
>    security in a given environment.  There is a trade-off between ease
>    of operational deployment where some portions of the IPv6 address
>    could be easily recognizable for operational debugging and
>    troubleshooting versus the risk of scanning; [SCANNING] shows that
>    there are scientifically based mechanisms that make scanning for IPv6
>    reachable nodes more realizable than expected.  The use of common
>    multicast groups which are defined for important networked devices
>    and the use of commonly repeated addresses could make it easy to
>    figure out which devices are name servers, routers or other critical
>    devices.
> 
>    While in some environments the perimeter 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 find myself on both sides of the prophylactic security discussion. I compare and network and its defenses to the human immune system, and perimeter security to the skin. I favor having a working perimeter security system much like I favor a functional skin, and for the same immunologic reasons. That said, the body provides the defense, reducing the rate at which it needs to bring other systems into play, and then assumes it has been breached; a person whose only immunologic defense is their skin is an AIDS patient, and doesn't have a good prognosis. My fundamental problem with most network security systems is that they over-emphasize perimeter security.

I say that because this paragraph seems to over-emphasize perimeter security - "in some environments the perimeter security is so poor...". I think I would say that "security is so poor". I would be tempted to go beyond to talk about the ways a remote network can be mapped, such as by observing email envelopes and addresses found in WWW logs etc, and the value of temporary random addresses (as opposed to permanent addresses, whether DHCP -assigned or MAC/SLAAC).

But I agree with the recommendation.

> 2.1.2.  Use of ULAs
> 
>    ULAs are intended for scenarios where IP addresses will not have
>    global scope.  The implicit expectation from the RFC is that all ULAs
>    will be randomly created as /48s.  Any use of ULAs that are not
>    created as a /48 violates RFC4193 [RFC4193].

Mention also that they are expected to not be announced, and if announced not accepted, in BGP?

>    ULAs could be useful for infrastructure hiding as described in
>    RFC4864 [RFC4864];

I believe that at least one cable operator uses them for cable modem addresses, which need no GUA and want to be hidden. Personally, I think that's a better use of a ULA - for something does doesn't actually need a global address. The paragraph here seems to assume that the only valid use of a ULA is as a counterpart to RFC 1918, and with NAT.

I'd really wish that we could talk about infrastructure (count the addresses in the envelope of this email; they are mostly infrastructure addresses) and internal-only services (wwwin-SERVICE.cisco.com names being a classic Cisco example, to my mind) when we start a paragraph with a comment on "infrastructure hiding", rather than proceeding directly to NAT.

> 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 disable SLAAC and
>    rely only on DHCPv6.  However, in scenarios where anonymity is a
>    strong desire since protecting user privacy is more important than
>    user attribution, privacy extension addresses should be used

No mention of IEEE 802.1X?

>    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, then ACL can rely on a /64 prefix per VLAN
>    rather than a per host ACL entry.

"then ACL"? Either I don't understand the sentence, or you meant "the".


> 2.1.6.  DHCP/DNS Considerations
> 
>    Many environments use DHCPv6 to allocate addresses to ensure
>    audibility and traceability (but see Section 2.6.1.5).  A main

audit-ability

>    security concern is the ability to detect and mitigate against rogue
>    DHCP servers (Section 2.3.2).

I think you want to say "counteract" rather than "mitigate against".

> 2.3.5.  3GPP Link-Layer Security
> 
>    The 3GPP link is a point-to-point like link that has no link-layer
>    address.  This implies there can only be an end host (the mobile
>    hand-set) and the first-hop router (i.e., a GPRS Gatewat Support Node

Gateway

> 2.4.  Control Plane Security
> 
>    RFC6192 [RFC6192] defines the router control plane and this
>    definition is repeated here for the reader's convenience.

Run-on sentence. Replace "and" with a period and capitalize the next word.

>    Modern router architecture design maintains a strict separation of
>    forwarding and router control plane hardware and software.  The
>    router control plane supports routing and management functions.  It
>    is generally described as the router architecture hardware and
>    software components for handling packets destined to the device
>    itself as well as building and sending packets originated locally on
>    the device.

I'm having trouble parsing the above sentence...

> The forwarding plane is typically described as the
>    router architecture hardware and software components responsible for
> 
> 
> 
> Chittimaneni, et al.   Expires September 22, 2016              [Page 11]
> Internet-Draft                 OPsec IPV6                     March 2016
> 
> 
>    receiving a packet on an incoming interface, performing a lookup to
>    identify the packet's IP next hop and determine the best outgoing
>    interface towards the destination, and forwarding the packet out
>    through the appropriate outgoing interface.

I'm having trouble parsing the above as well. I'd suggest breaking it into 2-3 sentences.

> 2.4.3.  Packet Exceptions
> 
>    This class covers multiple cases where a data plane packet is punted
>    to the route processor because it requires specific processing:
> ...
>    o  processing of the hop-by-hop extension header;

May I suggest the authors comment on draft-ietf-6man-hbh-header-handling as it progresses? Let's not let that and this conflict.

> 2.6.1.1.  Logs of Applications
> ...
>    #!/usr/bin/perl ?w

Should that be "-w"?

>    use strict ;
>    use warnings ;
>    use Socket ;
>    use Socket6 ;
> 
>    my (@words, $word, $binary_address) ;
> 
>    ## go through the file one line at a time
>    while (my $line = <STDIN>) {
>      chomp $line;
>      foreach my $word (split /[ \n]/, $line) {

replace "[ \n]" with "\s+". \s includes any white space character, including a space, a tab, \n, \r, and a couple of others. The "+" specifies strings of one or more in length.

>        $binary_address = inet_pton AF_INET6, $word ;
>        if ($binary_address) {
>          print inet_ntop AF_INET6, $binary_address ;
>        } else {
>          print $word ;
>        }
>        print " " ;
>      }
>      print "\n" ;
>    }


> 2.7.1.  Dual Stack
> 
>    Dual stack has established itself as the preferred deployment choice
>    for most network operators without a MPLS core where 6PE RFC4798

without *an* MPLS core...

> 2.7.3.2.  NAT64/DNS64
> 
>    Stateful NAT64 translation [RFC6146] allows IPv6-only clients to
>    contact IPv4 servers using unicast UDP, TCP, or ICMP.  It can be used
>    in conjunction with DNS64 [RFC6147], a mechanism which synthesizes
>    AAAA records from existing A records.
> 
>    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].

You might want to mention 6145, draft-bao-v6ops-rfc6145bis, and SIIT-DC.

> 3.1.  External Security Considerations:

You mention having a firewall that only permits inbound traffic that corresponds to an active session. Would RFC 6092 be worth mentioning in that context?

> 5.  Residential Users Security Considerations

Would RFC 6092 be worth mentioning in this context?